Event Notifications & Webhooks
FrankieOne provides real-time notifications through webhooks to keep your systems updated about important events and changes.
To set up webhooks, contact help@frankieone.com with your designated contact email. You can configure multiple webhook endpoints for different notification types. Ensure your endpoint is accessible via HTTPS.
FrankieOne uses webhooks to send real-time notifications about events in your system, such as a workflow completing or an entity’s risk profile changing. This allows you to build automated, event-driven integrations.
Available Notifications
Notifications triggered when a workflow execution completes, providing updates on the final status and outcome.
Notifications for IDV biometrics events, such as token requests, results retrieval, errors, and expirations.
Notifications related to entity events, such as onboarding, updates, and errors.
Workflow Events
FrankieOne sends notifications to keep you informed about workflow events. These notifications are sent to your configured webhook endpoint.
Workflow Error Events
Notifications related to errors workflow events are sent to your webhook endpoint.
IDV Biometrics Events
Notifications related to IDV biometrics events are sent to your webhook endpoint.
IDV Biometrics Error Events
Notifications related to errors in IDV biometrics events are sent to your webhook endpoint.
Entity Profile Events
FrankieOne sends notifications to keep you informed about entity profile events. These notifications are sent to your configured webhook endpoint.
Webhook Structure
All V2 webhooks share a consistent structure. The payload contains two key fields, notificationType and function, which you should use to determine how to process the event.
notificationType: Indicates the nature of the update. For most V2 use cases, this will be EVENT.
function: This field specifies the exact event that occurred. All function names use PastTense.
The payload for every webhook consists of a base schema of common fields, with additional event-specific fields included depending on the function.
Base Payload Schema
These fields are present on every webhook notification.
Event-Specific Fields
Depending on the function, additional fields will be present in the payload to provide specific context.
You can choose to receive all or specific notifications based on your needs. The notificationType
field in the payload indicates the type of notification.
Endpoint Format
FrankieOne appends the requestID
to your configured webhook endpoint:
Payload Examples
Handling Notifications
Receive the Webhook
Your endpoint should respond with a 200
or 202
HTTP status code to acknowledge receipt. If your endpoint returns a 5xx
or 4xx
status code (other than 400
), the system retries delivery multiple times over a period. A 400
status code stops retries.
Additional Security (JWT Authentication)
FrankieOne supports JSON Web Token (JWT) authentication to enhance the security of webhook notifications. By enabling JWT signing, you can verify the authenticity and integrity of the payloads sent to your webhook endpoint.
Notification payloads are secured through HTTPS and IP whitelisting. You can also enable JSON Web Token (JWT) signing for additional security. Contact support to enable JWT verification for your account.
JWT Structure
Security Features
- RSA-4096 bit private key encryption
- Customer-specific public key for verification
- HTTPS with secure algorithms
- IP whitelisting
Retry Mechanism
FrankieOne employs a robust retry mechanism to ensure reliable delivery of webhook notifications:
- Initial Retry: Immediately after the first failure.
- Exponential Backoff: Retries occur at increasing intervals.
- Maximum Retries: Up to 50 attempts over 24 hours.
If all retries fail, the message is moved to a Dead Letter Queue (DLQ), and FrankieOne’s support team is notified. Contact support to retrieve messages from the DLQ if necessary.