DigiCalls Developers / Testing & troubleshooting

Test the whole connection.

Check credentials and rendering first, then test delivery, replies and your application’s own business action.

Optional: test with Postman

Postman is a request-testing tool for developers, not a CRM or a required part of your connection. Your application communicates directly with DigiCalls. You can use the cURL examples or your existing development tools instead.

If you choose Postman, download the credential-free collection and import it:

Download Postman checks Download OpenAPI

Create a short-lived key with account:read, sms:read and sms:templates:read.
Store the key in Postman Vault as digicalls-api-key. The collection’s Bearer authorization uses {{vault:digicalls-api-key}}.
Set expectedAccountId to your business’s public Customer ID.
Run Account and templates. These checks read configuration and preview text; they contain no SMS-send request.
For optional checks, grant the required read scopes and set checkWebhooks or checkAutomations to true. Set a known messageId or runId to inspect that record.

If downloading is unavailable in your browser, open the collection link and import its JSON into Postman. Do not export keys with a shared collection.

Connect a CRM or an integration platform

Use your CRM’s server extension or an HTTP module in an integration platform such as Make. This is an HTTP API integration; a ready-made connector for every CRM is not included.

Trigger: choose the event in your app, such as a new service request.
Map: convert the recipient to E.164, select your approved sender and map your fields to the template’s variables.
Submit: POST to the SMS or automation endpoint. Put the key in the platform’s protected connection/secret store. Derive a stable idempotency key from your source event.
Store: save the returned message/run ID with the original record.
Receive: configure a signature-verifying webhook receiver. Fetch the indicated message, then update your CRM record.
Recover: deduplicate events, handle timeouts and keep a queue for failed CRM actions.

For Make, preserve the raw webhook body and headers for verification. A generic webhook inbox that returns 200 before your scenario runs proves receipt only. For production processing, use a receiver that verifies signatures and durably stores events before acknowledging them.

Receiver implementation →

An end-to-end acceptance test

Check	Expected evidence
Account	The returned public Customer ID matches your business.
Preview	The rendered text, variables and segments are correct; nothing is sent.
One authorized SMS	Your selected consenting test recipient receives exactly one message. Save its ID.
Retry	Same key/payload returns the same ID and duplicate:true; no second SMS.
Delivery status	The API reports the carrier result; 202 alone is insufficient.
Incoming reply	The recipient replies; your receiver verifies the event and your app retrieves that message.
Duplicate notification	Your application handles the event once, even if the notification repeats.
Invalid signature	Your receiver rejects a tampered or expired signature before any CRM action.
STOP and consent	The opt-out is reflected and further sending is blocked. Do not override the opt-out to finish a test.
Business action	The correct CRM/customer record is updated, with no cross-account data.
Cleanup	Pause temporary hooks, revoke temporary keys and remove secrets from test connections.

A working API call does not by itself prove your CRM mapping, recipient consent, carrier approval or business workflow. Complete those checks for each integration.

Understand API errors

Public errors contain error and requestId; SMS errors also provide a category code. X-Request-Id carries the same correlation ID. Keep the ID for support without logging message bodies or secrets.

HTTP response	Next step
400	Check JSON, supported fields, phone format, variable values, UUIDs and timestamps.
401	Check the Bearer key, expiry and revocation. A browser session token is not an API key.
403	Check the exact key permissions and account/API/SMS access.
404	Use the correct public ID for this business. Cross-account resources are not accessible.
409	Check setup/consent, idempotency conflict, stale revision or cancellation eligibility. Resolve the cause before retrying.
413	Reduce the JSON body. SMS and automation API payloads are limited to 16 KB.
429	Wait for Retry-After. Reduce request rate; retain the same idempotency key when retrying a write.
503	Service unavailable. Back off. For an uncertain send, keep the original key/payload and check the saved ID.

SMS_NOT_READY means approved setup or sending is missing. SMS_SENDER_UNAVAILABLE means the selected number is not the approved sender. SMS_IDEMPOTENCY_CONFLICT means that key was already used with another payload.

Rate limits and timestamps

Default API limits are 60 requests per key per minute, 120 per business per minute and 10,000 per business per UTC day. Your assigned limits may differ. These are separate from SMS segment allowance and automation limits.

On rate limiting, inspect Retry-After, X-RateLimit-Limit, X-RateLimit-Remaining and X-RateLimit-Reset. Use bounded backoff rather than tight polling.

Automation timestamps must include Z or a UTC offset. Convert your application’s local business time to an explicit instant; do not send an offset-free time.

Keep credentials and customer data private

Use a separate key for each integration and business, with the smallest necessary permission set and a suitable expiry.
Store API keys and webhook signing secrets on trusted servers. They are different secrets with different purposes.
Restrict access to message text and phone numbers in your app, logs, integration history and backups.
Use fixed DigiCalls API origins; do not follow arbitrary URLs from untrusted input with a Bearer key.
When rotating a key, account for scheduled work bound to the original key. Rotate a webhook secret on both sides, test and re-enable.

For help, contact DigiCalls with the time, endpoint, HTTP status and request ID. Do not send your key, signing secret or unnecessary customer messages. Contact DigiCalls →

Examples for your own server

SMS client · Node.js — defaults to template preview; sending requires an explicit action and recipient configuration.
Automation client · Node.js — defaults to listing rules; explicit event/schedule actions can send messages.
Webhook receiver · Node.js + PostgreSQL — raw-body signature verification and durable event deduplication.
OpenAPI 3.0 schema — request contracts for account, SMS, templates, Webhooks and automations.

Examples require your application’s own configuration. No credentials, actual customer records or test recipient numbers are included.