Zapier or a Custom Build? Rex CRM Exposes 35 Operations Through Zapier and 2,620 Through Its API

A Zapier app is not the vendor's API. It is a selection from it, built and maintained by the vendor or a partner, exposing the operations they decided were worth the maintenance cost. Treating "it has a Zapier integration" as equivalent to "it is integrable" is the mistake that derails these projects. Rex publishes both sides. Its documentation site is backed by unauthenticated endpoints on the live production API, which is how the service and method catalogue can be counted directly rather than estimated. The API is POST only, on a flat token authentication, at endpoints shaped as service and method pairs. Forty three of the 278 services carry full OpenAPI documentation. Here is the complete Rex connector surface as published on Zapier. | Type | Count | What the connector exposes | |---|---|---| | Triggers | 20 | Appraisal Created; Calendar Event Created; Calendar Event Updated; Contact Created; Contact Updated; Tag Added to Contact; Contract Created; Contract Status Changed; Lead Created; Listing Created; Listing Updated; Listing Published; Listing Sold or Leased; Tag Added to Listing; Contact Added to Mailing List; Contact Removed From Mailing List; Note Created; Open Home Attendee Added; Property Updated; Tag Added to Property | | Write actions | 11 | Send Email; Assign Lead; Create Lead; Create Match Profile; Create Note; Create Reminder; Send SMS; Add Tag; Remove Tag; Create Track; Remove All Tracks | | Search actions | 4 | Search for Full Calendar Event; Search for Full Contact; Search for Full Listing; Search for Full Property | That is a genuinely useful surface. Lead capture, tagging, notes, reminders and messaging are all covered. If your workflow lives inside those thirty five operations, a connector is the right answer and hiring a developer would be waste.

The precise shape of the gap is worth stating, because it is a pattern rather than a random set of omissions. Through Zapier you can create a Reminder, a Note, a Lead, a Track and a Match Profile, and you can send an email or an SMS. You cannot create or update a Contact, a Listing, a Property or an Appraisal. Everything the connector can write is peripheral. Everything that writes to a core record requires the full API. Once you see it, the boundary makes sense: the vendor exposed the operations where a bad write is cheap to undo, and withheld the ones where a bad write corrupts the agency's actual database. Be careful about what this does and does not prove. It does not mean the missing operations are impossible. Appraisals::create exists in the Rex API, alongside read, update, search, searchGrouped, autocomplete and a commission estimate method. Contacts::create exists. Listings has 30 documented methods including create and update. These are Zapier-specific limits, not platform limits. That distinction changes how you scope a project. "Rex cannot do this" is a reason to abandon a workflow. "Rex can do this but the connector cannot" is a costing question, and usually a small one. A single missing write is often a short worker process sitting alongside the Zaps rather than a rewrite of everything. So the honest version of the test is: check the connector list first, and when something is missing, check the API catalogue before you conclude anything.

Rex's API rate limit is 3,600 requests per hour per agency account, which is one request per second sustained. Rex describes the limit as currently soft and states that it will be strictly enforced in future. You may exceed 3,600 per hour across multiple agency accounts, but not within one. That number is the binding design constraint on any Rex automation, and it rules out the naive approach immediately. A per-contact loop over a database of 3,000 contacts consumes 3,000 requests. Do that hourly and you have spent your entire budget on reading data you already had. Batch and cache, never loop per contact in real time. The good news is that Rex's search endpoints are built for exactly this. Search result formats and their limits are documented per service: the default format returns 100 rows for Contacts and Appraisals and 500 for Reminders, the etags format returns up to 50,000 rows, and the ids format returns up to 1,000,000. Contacts also offers a name_etags format capped at 10,000. No connector exposes those formats. Zapier's search actions return one full record at a time, which is correct for a connector and useless for a bulk operation. If your workflow needs to reason about the whole database rather than one record, you are outside connector territory by definition, not by preference. Reads and searches on Listings, Contacts, Buildings and Properties also accept field and extra field arguments for partial responses. Smaller payloads do not save you requests, but they save time, which matters when a 10 second budget is in play elsewhere.

Rex supports 50 plus webhook events covering create and update across its common services, and webhooks are available on all subscription tiers rather than being gated behind an enterprise plan. Two payload formats exist: one sending the full pre and post record states, and one sending only the service, record id, account id and triggering user, leaving you to fetch the record. The delivery health rules are where an honest comparison earns its keep. A webhook is marked unhealthy if Rex sees a failure rate of at least 99% over a 24 hour period. A failure is any response code outside 102, 200, 201, 202 and 204, or a response taking 10 or more seconds. Once unhealthy, delivery stops entirely and must be manually restored. The consequence is the part that catches teams out: any events that occurred while the webhook was unhealthy will not trigger the webhook. There is no replay. A slow receiver during a busy afternoon can lose a day of listing updates and give you no signal that it happened. This is why Rex's own recommended architecture is a nightly e-tag sync running alongside the webhook delivery system. E-tag sync means asking a service for id and version pairs in bulk, comparing them against your local state, and fetching only what changed. Rex explicitly recommends periodic sync over live per-request API calls in almost every situation. A connector cannot give you that. Zapier consumes webhooks; it does not run a reconciliation pass to find what it missed. Building a system that is correct rather than usually correct is a direct-API job, and a receiver that acknowledges immediately and processes asynchronously is table stakes because of the 10 second budget.

A Rex integration authenticates as a real Rex user, and Rex states plainly that the integration user counts against the agency's user slots. In Rex's own words, agencies are likely to be wary of adding integrations because it can add to their monthly fees. That is a genuine cost of the direct path and it belongs in the comparison. The custom build does not just cost development time. On day one it may also add a paid seat to your client's subscription, forever, and you will be the one explaining why. Rex's answer is the Verified Integrator programme. Once verified, the integration user no longer consumes a paid seat. The prerequisites are specific: the integration must already be built, it must be live in at least one client account, and it must send an app identifier header in the documented format. Application is by form, with an outcome quoted at 5 to 10 business days. Read the sequencing there, because it is the awkward part. You cannot be verified before you build, and you cannot be verified before you have a live client. So the seat cost applies during exactly the period when you are least able to justify it, and it clears only after you have shipped. There is a second access constraint worth pricing. There is no public app marketplace or developer console self-signup for Rex. Authentication is a username and password for a real user in a client's account, which means you get access by being invited in. That is a scheduling dependency on somebody else's inbox, and it almost never appears in a project estimate. Put it in as its own task and start it first.

Stay on the connector when three things are true at once: the trigger and the action you need both appear on the published list, the volume is modest, and the logic is linear. If all three hold, a custom build spends money to reach the same outcome more slowly. Linear matters more than people expect. Connector platforms are good at "this happened, so do that, then do the next thing". They are poor at anything that needs to remember what happened three steps ago, branch on the result, wait for something external, and resume. You can force it with stored records and lookup steps, but you are then building a state machine out of parts that were not designed to be one, and it will be harder to debug than the code it replaced. Volume matters because of the meter. Zapier prices per task, so every action step counts. At low volume that is cheap and you should not think about it. At high volume it becomes a line item worth comparing against the cost of hosting your own worker process, and against the seat cost described above. It is also worth checking whether the CRM already does the thing natively before you reach for either option. Rex ships automation rules, workflows with cron expressions evaluated in the account's timezone, and Tracks, which are its own multi-step follow-up sequences. Recurring reminders with scheduled send are native record fields, not an add-on. Our honest opinion, having built both, is that most small businesses should start on a connector and stay there longer than a developer would tell them to. The failure mode we see most often is not outgrowing Zapier. It is a custom build commissioned for a workflow three Zaps would have handled, which then sits unmaintained because nobody in the business can change it. Before commissioning anything, run the process manually three times first.

Move to a custom build when any one of five conditions holds. These are structural rather than matters of taste. Each describes something a connector platform cannot do, not something it does badly. One, you need to write to a core record. On Rex that means creating or updating a Contact, Listing, Property or Appraisal, none of which the Zapier app exposes. The API methods exist, so this is a costing question rather than a dead end. Two, you need to operate on the database in bulk. Anything that reasons across thousands of records needs the etags or ids search formats and their 50,000 and 1,000,000 row limits, and needs to respect 3,600 requests per hour. Connector search actions return single records. Three, you need delivery you can trust. Webhooks that fail closed and never replay missed events mean a reconciliation pass is mandatory in practice, not optional. Rex recommends a nightly e-tag sync alongside webhooks for exactly this reason. Four, the workflow needs to hold state across steps, pause, and resume, or needs a human approval gate with an audit trail. Any workflow sending messages to real customers should have one of those gates, and it is a poor fit for a linear task runner. Five, per-task pricing at volume exceeds the cost of running your own worker. Work out your actual monthly task count first. Most businesses guess high, then commission a build they did not need.

Rex's CRM API terms say you may not copy or store data except as expressly permitted or with written consent, and that where data is cached you should refresh the cache at least every 24 hours. All data must be stored and served using strong encryption, and you must delete all data collected from users on request. Read the 24 hour rule again, because it rules out a common design. You cannot maintain a long-lived local mirror of a client's Rex database and query that instead of the API. Anything you hold is a cache with an expiry, not a copy. If your plan involved syncing the CRM into your own warehouse and building reporting on it, that plan needs rewriting before anyone estimates it. Note the tension with the recommended nightly e-tag sync: a sync that refreshes within the window is a cache, a sync that accumulates history is not. You may not sell, rent, lease, sublicense, redistribute or syndicate access to the API. If you were planning to build something you resell to multiple agencies, each customer holding their own relationship with the vendor is the shape these terms push you towards. Contact information obtained through the API cannot be used for external outreach without the contact's express permission, and data may not be used in any advertisements. That clause sits on top of your Australian obligations rather than replacing them, and it points the same direction. Rex also expressly reserves the right to offer products or services similar to your application. Build accordingly. None of this changes if you use Zapier instead of writing code. The terms attach to API access, and a connector app is API access with a friendlier face.

How do I know whether my workflow fits inside a connector? Write down the trigger and every action in plain English, then check each one by name against the vendor's connector listing. For Rex that is 20 triggers, 11 write actions and 4 search actions. If every item matches, you are safe. If any item does not, check the API catalogue before concluding it is impossible, because Rex's API carries 2,620 methods across 278 services. Can Zapier create an appraisal in Rex? No, and this is the clearest example of the gap. The Zapier app has an Appraisal Created trigger but no create-appraisal action, so you can react to appraisals without being able to record them. The Appraisals::create method does exist in the Rex API, along with read, update, search and autocomplete. It is a connector limit, not a platform limit. What is the Rex API rate limit and why does it matter? 3,600 requests per hour per agency account, which is one request per second sustained. Rex describes it as soft today and says it will be strictly enforced in future. It rules out per-contact loops in real time and pushes you towards batched search calls and a local cache, which is a fundamentally different architecture from a connector firing one request per event. Are Rex webhooks reliable enough to build on alone? Not alone. A webhook is disabled if it fails at least 99% of the time over 24 hours, where a failure includes any response taking 10 or more seconds, and events that occurred while it was unhealthy are never replayed. Rex's own recommendation is to run a nightly e-tag sync alongside webhook delivery, which is a direct-API job. Does a custom Rex integration cost my client a paid seat? Initially, yes. Rex states that the integration user counts against the agency's user slots and that agencies are wary of the added monthly fee. The Verified Integrator programme removes that cost, but it requires the integration to already be built, live in at least one client account, and sending the app identifier header, with an outcome quoted at 5 to 10 business days. Does using Zapier get me around the vendor's API terms? No. The terms attach to API access, and a connector app is API access. The 24 hour cache refresh rule, the ban on redistributing access, the deletion obligation and the requirement for express permission before marketing to contacts obtained through the API all apply the same way regardless of which tool sits in the middle.