Async Verify — Bank

Verify Thai bank transfer slips asynchronously. Instead of waiting for the result in the HTTP response, you enqueue one or more slips and receive each result via a webhook callback (with a polling fallback).

This runs alongside the synchronous POST /verify/bank — the sync endpoint is unchanged. Use async when you need to:

• Verify in bulk (submit up to 100 slips in one call).
• Decouple accepted requests from verification using a queue. Async is not a rate-limit bypass: submission can return 429 RATE_LIMIT_EXCEEDED; accepted jobs may wait for worker capacity.
• Verify slips whose data is slow to arrive (e.g. Bangkok Bank), where the job retries in the background within the retry budget below.

Base URL

https://api.easyslip.com/v2

Authentication

Required. Uses the same branch API key as the synchronous verify endpoints. See Authentication Guide.

Authorization: Bearer YOUR_API_KEY

Endpoints

Endpoint	Method	Description
/verify/bank/async	POST	Enqueue one slip → 202 with a jobId
/verify/bank/batch	POST	Enqueue many slips (max 100) → 202 with a batchId + jobs
/verify/bank/jobs/:jobId	GET	Poll a job's status/result (fallback if you miss the webhook)

Each enqueued slip produces one webhook callback — including each slip inside a batch (one callback per slip, not one per batch).

How it works

1. Enqueue a slip with POST /verify/bank/async (or many with /batch). You get back a jobId immediately (202 Accepted) — the slip has not been verified yet.
2. A bank not_found result or BBL pending is retried up to four times after 30/60/120/240 seconds (five checks total). The scheduled delay totals 7m30s, plus processing and queue delays. Success finishes immediately.
3. EasySlip queues a webhook with success, not_found, or failed. Success contains sync-shaped data; failed contains data: null and safe error.code/message. Retryable billing outages send failure only after their own retry budget is exhausted.
4. If you miss the webhook, GET /verify/bank/jobs/:jobId returns the job record (retained ~7 days).

Providing a callback URL

Each request may include a callbackUrl. If omitted, your branch's configured default webhook URL is used.

Rule	Behaviour
callbackUrl provided	The result webhook is POSTed there (overrides the branch default)
callbackUrl omitted	The branch's configured default webhook URL is used
Neither set	400 VALIDATION_ERROR
Not https	400 INVALID_CALLBACK_URL
Resolves to a private/internal address	400 INVALID_CALLBACK_URL

HTTPS only

callbackUrl must be a public https:// URL. Non-HTTPS URLs and URLs that resolve to private/internal IP ranges are rejected for security.

The default webhook URL and the signing secret are configured in your branch's webhook settings. See the webhook callback page for signature verification.

Quota & duplicates

Async verification behaves the same as sync for billing:

• Quota — only a successful verification consumes quota. Failures and duplicates do not.
• Duplicates — set checkDuplicate: true to receive isDuplicate for slips previously verified by the same branch via sync or async. The default is false, which omits the field. Same-branch duplicates do not consume quota again.

Error Codes

Code	HTTP Status	Description
VALIDATION_ERROR	400	Invalid body, an empty slip, a batch over 100 slips, or a missing callbackUrl with no branch default
INVALID_CALLBACK_URL	400	callbackUrl is not https, or resolves to a private/internal address
JOB_NOT_FOUND	404	Unknown/expired job, or a job not owned by your branch

Standard authentication errors (MISSING_API_KEY, INVALID_API_KEY, SERVICE_EXPIRED, QUOTA_EXCEEDED, …) also apply. See Error Codes Reference.