External API Dispatching

Send data from Answering Service Care to external systems through HTTP-based workflows.

Use External API Dispatching when Answering Service Care needs to send data to another system.

This is useful for real-time routing, downstream automation, and client-specific workflow handoffs.

What it is

External API Dispatching sends ASC data to an external HTTP endpoint as part of an operational workflow.

It fits cases where another platform needs to react to events created inside ASC.

Common examples:

• create or update a CRM record
• open a help desk ticket
• trigger an external scheduling or escalation workflow

When to use it

Use External API Dispatching when ASC should push data outward.

Use Zapier when you want a low-code SaaS automation layer for non-sensitive data.

External API Dispatching sends data directly from ASC to your own endpoint, with no third party in between, so it is the right choice for HIPAA-sensitive workflows that require secure delivery. (By contrast, Zapier routes data through a third-party service and should not be used for PHI.)

Configure it in the Oncall Calendar

External API Dispatching is set up as an External API delivery method on an Oncall contact. When a message reaches that contact, ASC sends an HTTP POST to the endpoint you define.

The External API delivery method, with URL, payload, field mappings, and headers.

Open the contact's delivery methods, choose External API, and configure:

Field	What it does
URL	The endpoint ASC POSTs to when a message reaches this contact. Use HTTPS.
Payload Type	The request body format. JSON is recommended.
Data	One or more value sets that build the request body. For each, enter the field name the receiving system expects and the ASC value to send.
Basic Auth	Optional username and password. Both are required to send a Basic Authorization header.
HTTP Headers	Custom headers such as Authorization, Accept, and Content-Type, use these for a bearer token or API key.

Map fields with merge variables

In each Data value set, the value can be a merge variable chosen from the Available variables list. Variables resolve against the message that triggered the dispatch:

Field (receiving system)	Value (ASC variable)
type_of_request	{{message.answers.reason_for_calling}}
details	{{message.content}}
severity	{{message.answers.severity}}

{{message.answers.<question>}} pulls a specific answer captured by your script, and {{message.content}} is the full message body. Select Add value set to map more fields.

The complete list of variables is shown in the Available variables dropdown when you configure the delivery method.

Example request

With the configuration above, ASC sends a request like this (secrets shown redacted):

POST to your endpoint

POST https://api.example.com/custom-objects/your_object/records/
Authorization: Bearer <YOUR_API_KEY>
Accept: application/json
Content-Type: application/json

{
  "type_of_request": "Billing question",
  "details": "Caller wants a copy of last month's invoice.",
  "severity": "Normal"
}

Never paste a real key into a screenshot or shared document. Store secrets only in the HTTP Headers or Basic Auth fields, and rotate any key that is ever exposed.

What to prepare

Before you configure dispatching, define these items:

• the destination HTTPS endpoint
• the required authentication method
• the payload fields the receiving system expects
• the success criteria for the receiving system

Keep the destination contract stable.

That makes workflow changes easier to manage across clients and teams.

Recommended endpoint design

Your external endpoint should:

• accept HTTPS requests
• validate authentication before processing data
• return a fast 2xx response on success

If downstream work takes time, queue it after the request is accepted.

That reduces timeout risk in production workflows.

Treat every dispatched request as production traffic.

Validate auth, log requests, and avoid exposing sensitive data in error messages.

Payload design guidance

Include identifiers that help the receiving system reconcile records cleanly.

Good payloads usually include:

• a stable ASC record ID
• account or client context
• timestamps and status values

Only send fields the target system needs.

That reduces mapping drift and support overhead.

Common dispatch patterns

CRM and ticket routing

Dispatch message or task data to a CRM, PSA, or ticketing platform.

This helps keep client systems aligned with live answering activity.

Escalation workflows

Dispatch urgent events to an external on-call, field service, or alerting workflow.

This is useful when response rules live outside ASC.

Reporting and warehousing

Dispatch operational records into a reporting pipeline for analytics and reconciliation.

This works well when business reporting runs outside the platform.

API alignment

If the receiving system also needs to call ASC, use the ASC API with the secure base URL:

https://secure.answeringservicecare.com

Use these references when you define payloads and downstream actions:

• API Reference
• Messages
• Call Recordings
• To Dos

Implementation checklist

Use this checklist before you go live:

1. confirm the destination URL and auth method
2. validate the payload with real sample data
3. log request and response results
4. test error handling with invalid data
5. confirm the receiving system handles duplicate requests safely

Troubleshooting

If dispatching does not behave as expected, check:

• endpoint availability
• auth headers or tokens
• payload field names and formats

Also confirm the receiving system can process ASC identifiers exactly as sent.

That prevents broken links between records and follow-up actions.