Create actions

Appends one or more actions to a lead's timeline. Only custom actions and PAYMENT actions can be written through this endpoint. Create timeline attachments through POST .../file.

Each action in the request is processed independently — failed entries don't block the rest. The response's actions array mirrors the request order; failed entries have action_id: null and status: IGNORED, with details in remarks.

Request

Field	Value
Method	POST
URL	https://next.telecrm.in/autoupdate/v2/enterprise/{enterpriseId}/lead/{leadId}/action
Auth	Bearer token (Sync-typed). See Authentication.
Headers	Content-Type: application/json

Path parameters

Name	Type	Required	Description
enterpriseId	string	yes	The enterprise (workspace) ID.
leadId	string	yes	The lead's ID.

Body

Field	Type	Required	Description
actions	array of object	yes	One or more custom or PAYMENT actions. Custom action type is the bare numeric code.

actions is the only key read from the body. Each entry takes one of two shapes.

Custom action entry

Field	Type	Required	Description
type	string	yes	The bare numeric code, e.g. "1001". The server prepends ACTION_ itself.
fields	object	yes	Field values keyed by API name. Omitting it, or omitting any field the definition marks mandatory, drops the entry.
created_on	string or number	no	Backdates the action. Epoch ms or DD/MM/YYYY HH:mm:ss. Honoured only when the action definition has allowPredatedActivity: ALLOW — otherwise dropped with a remark. Check it via GET /custom-actions?detail=true.
employeeid	string	no	Email of the team member who performed the action. Defaults to the telecrm system user. See Attributing an action.

PAYMENT entry

Field	Type	Required	Description
type	"PAYMENT"	yes	Literal.
status	string	yes	One of PENDING, COMPLETED, FAILED, REFUNDED, CANCELLED, PROCESSING. Case-insensitive.
currency	string	yes	One of the 14 supported currencies — see Actions → PAYMENT. Case-insensitive.
amount	number or numeric string	yes	Must be greater than 0.
employeeid	string	no	Email of the team member who recorded the payment. Defaults to the telecrm system user.

All four required PAYMENT fields must be sent together — omitting any one drops that entry.

FILE fields on a custom action

FILE fields are not accepted in this request. First create the custom action, then use POST .../action/{actionId}/file to store its file references and receive the presigned upload URLs. Mandatory FILE fields do not block the initial action creation because they must be populated through that second endpoint.

Attributing an action to a team member

By default an action created through the API is attributed to telecrm, the system user, and shows that way on the lead's timeline. Pass employeeid with a team member's email address to attribute it to a real person instead:

{
  "type": "1001",
  "employeeid": "agent@company.com",
  "fields": { "note": "Site visit completed" }
}

• The email must belong to an active team member in the workspace. Look one up with GET /team-members.
• employeeid sits at the top level of the action entry, not inside fields.
• If the email doesn't resolve, the two kinds behave differently, as everywhere else: a custom action is still created and attributed to telecrm, with an IGNORED remark on actions[<index>].employeeid; a PAYMENT entry is dropped entirely.
• The same field works on the Async API and on the actions array of POST /lead.
• It cannot be changed afterwards — employeeid is immutable on update.

Example request

curl -X POST "https://next.telecrm.in/autoupdate/v2/enterprise/{enterpriseId}/lead/603d2b2f9b1e8a001c8e4f5c/action" \
  -H "Authorization: Bearer YOUR_SYNC_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "actions": [
      {
        "type": "1001",
        "fields": { "note": "Demo scheduled" }
      },
      {
        "type": "PAYMENT",
        "status": "PENDING",
        "currency": "INR",
        "amount": "10000"
      }
    ]
  }'

Responses

201 Created

Per-action status. The lead itself is unchanged on validation failures.

WARNING

This endpoint returns the lead's ID as leadid. POST /lead returns the same value as lead_id. The two spellings are not interchangeable.

{
  "leadid": "603d2b2f9b1e8a001c8e4f5c",
  "actions": [
    { "action_id": "603d2b2f9b1e8a001c8e4f5d", "status": "CREATED" },
    { "action_id": null, "status": "IGNORED" }
  ],
  "remarks": [
    { "field": "actions[1].fields.email", "status": "IGNORED", "remark": "Email is invalid" }
  ]
}

401 Unauthorized

See the universal 401 in the overview.

404 Not Found

{
  "error": {
    "code": "LEAD_NOT_FOUND",
    "message": "Lead with ID 62ab16e was not found."
  }
}

Notes

• Custom action type is the bare numeric code ("1001") — no ACTION_ prefix. See Actions for the full custom-action format and how to find codes.
• There is no request-level action-type check. Posting a built-in type such as INCOMING_CALL does not fail the request — the entry fails the custom-action lookup and comes back as IGNORED with Custom action with code 'INCOMING_CALL' not found.
• Actions are appended in the order provided.
• Custom and PAYMENT entries fail differently. A PAYMENT entry is dropped outright if anything about it is invalid. A custom action is still created when a non-mandatory field fails validation — that one field is dropped and reported in remarks. Read remarks even for entries marked CREATED.
• See Pitfalls for action-type restrictions and per-action partial-success handling.