Token lifecycle
A team can keep up to 10 active tokens, label each for production, staging, or development, assign validate and usage scopes, and revoke a token individually.
Connect Soryxa validation decisions to other systems with scoped API tokens, inbound validation webhooks, outbound event delivery, OpenAPI, and Postman assets.
Integration model
Create separate production, staging, and development tokens where useful. New tokens should use the smallest scope set that covers the endpoints they call.
| Scope | Access |
|---|---|
| validate | POST /api/v1/validate and all /api/v1/batch endpoints. |
| usage | GET /api/v1/usage for current usage and remaining validation allowance. |
| validate + usage | GET /api/v1/credentials/verify requires both scopes to verify integration credentials without consuming a validation credit. |
| Empty scopes | Legacy full-access tokens. Prefer explicit scopes for new production tokens. |
GET /api/v1/credentials/verify accepts a bearer token and returns success: true with data.authenticated: true and data.required_scopes: [validate, usage] when both scopes are available. It remains usable when subscription capacity is exhausted or inactive and does not consume a validation credit. A token missing either required scope receives 403 INSUFFICIENT_SCOPE.
A team can keep up to 10 active tokens, label each for production, staging, or development, assign validate and usage scopes, and revoke a token individually.
A new token value is displayed once and masked after you leave or refresh. Optional controls set a per-token requests-per-minute limit and a rotation reminder from 1 to 365 days.
Send GET /api/v1/usage with a bearer token carrying the usage scope to read current plan usage without consuming a validation credit.
Inbound connector webhooks use the integration slug and team public UUID. Generic webhook-compatible connectors accept a top-level email or email_address and optional metadata. Signed connectors are verified before work is queued.
POST /api/v1/integrations/webhook/{teamPublicUuid}/{slug}
Content-Type: application/json
{
"email": "user@example.com",
"metadata": {
"workflow": "signup"
}
}
Provider-specific handlers may support other payload shapes. Use the setup guide for the connector configured in your Soryxa workspace.
For n8n inbound requests, include a non-empty top-level delivery_id of at most 255 characters and a timestamp within five minutes of server time. Send X-Soryxa-Signature as the lowercase hexadecimal HMAC-SHA256 of the exact raw JSON body using the connector signing secret, without a sha256= prefix. Keep the delivery_id stable when retrying the same event. A first accepted request returns 202 validation_accepted; an accepted replay returns 200 validation_already_accepted without queuing or charging a second validation. Replays must still pass signature and timestamp checks.
This example shows the custom-webhook and n8n envelope. Use event and source to route each payload. Inbound validate actions require an active outbound or bidirectional connector with read_results, a configured webhook URL, and a subscription to validation.completed or validation.failed. Otherwise the request returns 422 no_result_webhooks_configured.
{
"delivery_id": "e6c47f48-6d7c-4f3b-b35f-49e508beeb53",
"event": "validation.completed",
"source": "soryxa",
"occurred_at": "2026-09-06T12:00:00+00:00",
"timestamp": "2026-09-06T12:00:00+00:00",
"data": {
"email": "user@example.com",
"decision": "allow",
"reason_code": "CLASSIFICATION_VALID",
"score": 96
}
}
Webhook receivers should verify the sender, parse event type, and keep validation decisions separate from delivery failures. All five supported outbound events are persisted for retry and dead-letter handling. In custom-webhook and n8n payloads, delivery_id and occurred_at stay stable across retries; timestamp identifies the delivery attempt. Deduplicate by delivery_id before applying downstream changes.
Default delivery handling makes up to five attempts, retrying after 30, 120, 300, and 600 seconds. A fifth failure becomes dead_letter; connector delivery controls can retry failed or dead-letter deliveries manually. When a custom-webhook signing secret is configured, verify X-Soryxa-Signature against the hexadecimal HMAC-SHA256 of the raw request body. n8n requires this signing secret. Provider-specific connectors can use different envelopes and authentication; follow their setup guide.
Configured outbound connectors receive a completed validation decision.
Configured outbound connectors receive a validation failure that needs fallback handling.
Configured outbound connectors receive a completed batch summary.
Connectors with the review_decisions scope receive an approved review outcome.
Connectors with the review_decisions scope receive a rejected review outcome.
Connector scopes are separate from API token scopes. Choose scopes based on whether the connector receives events, triggers validation, or both.
| Connector scope | Access |
|---|---|
| validate | Allows inbound or bidirectional connectors to trigger Soryxa validation. |
| read_results | Allows outbound connectors to receive validation result data where supported. |
| read_usage | Allows connectors to read usage and allowance information where supported. |
| review_decisions | Allows outbound connectors to receive review queue decision events where supported. |
Connector availability may depend on account configuration and provider setup. Custom webhook is the most direct pattern for systems that can receive HTTPS JSON events.
Trigger no-code workflows from Soryxa validation and batch events.
Connect Soryxa events to Make scenarios for routing, alerts, and record updates.
Use Soryxa decisions inside self-hosted or managed n8n workflows. A signing secret of at least 16 characters is required for the connector in every direction.
Use email-quality decisions in identity and signup-related workflows where configured.
Use Soryxa validation from Clerk webhook or server-side signup handlers.
Use Soryxa validation with Supabase Auth signup or auth-hook workflows.
Use Soryxa validation with Firebase authentication workflows.
Use Soryxa validation in NextAuth or Auth.js server-side signup flows.
Use Soryxa validation in Laravel app signup and account intake flows.
Send Soryxa events to any HTTPS endpoint that can verify the request and process JSON payloads.
Use the OpenAPI file to generate clients or review response schemas. Use the Postman collection, workspace manifest, and environment file for a quick authenticated request from a local workspace. These four asset URLs require an authenticated Soryxa browser session.
The Postman collection includes runnable requests named Validate Email, Get Usage, Create Batch, List Batch Jobs, Get Batch Status, Get Batch Results, Export Batch Results, Get Batch Credits, Cancel Batch, and Trigger Integration Webhook.
The activation screen prioritizes four core outcomes: a usable API token, a published policy, a playground decision, and a production API decision through a server-side proxy. Usage-log evidence and the Postman collection remain optional verification and developer-handoff tools.
elvesora/soryxa-laravel
composer require elvesora/soryxa-laravel
elvesora/soryxa-php
composer require elvesora/soryxa-php
Soryxa sign-in required
https://soryxa.elvesora.com/integrations/openapi.yaml
Soryxa sign-in required
https://soryxa.elvesora.com/integrations/postman-collection.json
Soryxa sign-in required
https://soryxa.elvesora.com/integrations/postman-workspace.json
Soryxa sign-in required
https://soryxa.elvesora.com/integrations/postman-environment.json