Connect the records.
Keep control of the work.

What is a CRM API?

A CRM API is a defined interface that lets another application read or change CRM information. A website might submit an enquiry, a reporting service might retrieve opportunities, or an internal tool might update a record. The interface specifies the accepted requests, authentication, data formats and responses. It does not decide your business rules for you.

An API is different from a finished integration. The API supplies the permitted operations; the integration decides when to call them, which records correspond, what to do with failures and who owns the resulting work. An endpoint that creates a contact is useful, but a contact without the right owner or next action can still disappear from the team’s process.

Write the outcome first: “A validated website enquiry creates traceable work for our team.” Then identify the minimum operations needed. Meibo has a dedicated enquiries endpoint for that workflow. Using a general record-writing API to rebuild an existing atomic operation creates more failure points than the task needs.

Specify the contract before writing the connector

For each operation, record the source, destination, required permission, accepted fields and success condition. Include the identity rule: are you creating a genuinely new item or updating a known record? A company name is a display label, not a reliable integration key. Preserve the destination ID and the source system’s ID in an integration-owned mapping where necessary.

Keep transport success separate from business success. A successful HTTP response may mean one record was saved, while your workflow needs a linked task as well. Define the final state and a way to reconcile it. If several requests are necessary, record which steps have completed so a retry resumes the workflow instead of starting every step again.

Inspect the actual response body rather than assuming the destination echoes your request. Server-generated identifiers, versions and normalised values become inputs to the next operation. Store those values with a correlation ID so support can investigate one workflow without searching unrelated customer data.

Use scoped access and a server-side boundary

An integration credential belongs in the service making the authorised request. For a public website, that normally means your server route calls the CRM while the browser calls your server. Putting a secret in browser JavaScript, a public environment variable or a form action exposes it to visitors. Hiding the button does not hide the credential.

Meibo API keys are workspace-bound and sent in the Authorization header using the Bearer scheme. The implementation checks the requested scope, expiry, revocation and whether the creator still has an owner or admin membership. Reading records requires records:read; writing them requires records:write; the enquiry workflow uses enquiries:write. Grant the narrowest combination needed [1].

Name the operational owner of the key and document replacement. Test revocation with a non-production credential: the old connection should stop working visibly, not quietly continue with a fallback key. Keep secrets out of screenshots, worksheets and request logs. Log the key identifier or integration name rather than the credential itself.

Read every page without mistaking a list for a change feed

Meibo’s record list accepts an optional kind, a limit from 1 to 100 and a cursor. The response contains data and next_cursor. Continue using the returned cursor until it is null. Fetching the first successful page does not establish that you retrieved every matching record [1].

The current cursor follows record IDs. It is not an updated-since cursor or a promise of a consistent snapshot while other people are editing. Design a repeated export or reconciliation with that limitation in mind. Do not use the last ID from yesterday’s listing as a way to find every record changed today.

For a large initial load, save progress after the destination has accepted the relevant batch. If your process stops halfway through, restarting should recognise records already applied. Reconcile identifiers and selected field values as well as totals: two lists can have the same count while containing different records.

curl --fail-with-body \
  "https://app.meibolabs.com/api/v1/records?limit=50" \
  -H "Authorization: Bearer $MEIBO_API_KEY"

Handle updates, conflicts and ambiguous timeouts

A record update must target a known identity. In Meibo, updating an existing record uses its id and version; a conflicting version produces a 409 response. Read the current state and decide whether the intended change is still valid. Blindly retrying an old payload with a newer version can overwrite work that a teammate just completed [1].

A timeout is ambiguous: the server may have saved a write before the response was lost. Repeating a create request without a documented retry contract can create a second record. Idempotency means repeating an operation has the same intended effect, not that every POST endpoint automatically provides that behaviour [2].

Use an endpoint’s explicit idempotency mechanism where available. Meibo’s enquiry endpoint requires an Idempotency-Key; its general records endpoint should not be assumed to share that contract. For multi-step integrations, design identity mapping, read-back checks and a durable operation log before deciding which failed requests can safely be retried.

Classify errors instead of retrying everything

Authentication failures need a credential check. Permission failures need a scope or membership check. A validation error needs a corrected request. A conflict needs a decision about current state. None becomes a successful operation merely because the worker repeats it quickly. Preserve a useful error category and a redacted explanation for the person responsible.

Rate limiting is different. Meibo currently limits a key to 120 requests per minute and returns 429 with Retry-After: 60 when that limit is exceeded. Slow the integration and honour the response rather than spreading the same work across more keys. Keep a bounded queue so an outage does not trigger an uncontrolled burst when service returns [1].

For transient failures, use a limited retry policy with backoff and jitter, then surface unresolved work. A dashboard saying “connected” is insufficient. The operator needs the age of the oldest pending item, the last confirmed success and a way to identify the records requiring attention.

Prove the complete workflow before launch

Run a representative create, read and update in a test workspace. Verify the resulting links, owner and visible next action in the CRM. Then repeat with invalid fields, an expired credential, insufficient permissions and an old record version. Record the expected outcome before each test and the observed outcome afterwards.

Test an ambiguous timeout deliberately in a controlled environment. Establish whether the write happened, then exercise your recovery path. Test more than one page of records and a worker restart midway through a batch. These cases reveal whether the connector is robust beyond its first successful request.

The worksheet below separates an API response from a business acceptance check. Assign an owner to each unresolved case. Ship a narrow, observable workflow first; add more objects and directions once that workflow can recover without someone editing the database by hand.

Common questions.