Overview
When a user opens a magic link and their data is incomplete for CIP verification, M2M sends auser.data_request webhook to your server. This gives you an opportunity to provide the missing data before M2M asks the user directly.
Data requests are non-blocking. The user continues through the widget while you fetch and send data. If you respond before they reach the CIP step, they skip data entry entirely.
The webhook
When M2M needs user data, you receive this webhook:Key fields
Possible required fields
Responding to the request
Make a PUT request to thereplyEndpoint with the user data:
Request body
string
required
Your user identifier. Must match the
referenceId in the webhook.object
required
Object containing the requested fields. You only need to include fields from
requiredFields, but you can include additional fields.Success response
Error handling
Reference ID mismatch (400)
ThereferenceId in your request doesn’t match the data request:
Data request not found (404)
ThedataRequestId doesn’t exist:
Data request expired (409)
The data request (and link) has expired:Implementation guide
Complete webhook handler
Node.js
Best practices
Respond quickly
Respond quickly
The faster you respond, the smoother the user experience. Aim to respond within a few seconds:
- Pre-fetch user data when you create links
- Use a fast database with indexed queries
- Consider caching frequently accessed data
Handle partial data
Handle partial data
If you don’t have all requested fields, send what you have. Partial data still reduces friction:
Validate data format
Validate data format
Ensure data matches expected formats before sending:
- Dates:
YYYY-MM-DDformat - CURP: 18 characters, uppercase
- Names: Use legal names, not nicknames
Log for debugging
Log for debugging
Log webhook receipt and your responses for troubleshooting:
Implement idempotency
Implement idempotency
Data requests are idempotent - you can respond multiple times safely. M2M only processes the first successful response.
What if you don’t respond?
If you don’t respond (or can’t provide data), M2M gracefully falls back:- User reaches the CIP step in the widget
- M2M shows a form for the missing fields
- User enters the data manually
- Transaction continues normally
Not responding doesn’t break the flow - it just increases friction for the user. Implement data requests when you’re ready, but don’t let it block your initial integration.
Testing
Sandbox testing
-
Create a link in sandbox with incomplete data:
- Configure your webhook endpoint in Partner Portal
- Open the link in your browser
-
Verify you receive the
user.data_requestwebhook - Send a response and verify it’s accepted
- Check that the widget shows pre-filled data
Testing without webhooks
If you’re not ready to implement webhooks:- Create a link with minimal data
- Open it and complete the full CIP flow manually
- Understand what users experience
- Use this to prioritize which data to provide upfront
Next steps
User Data Guide
Understand the friction vs. integration trade-off.
Webhook Security
Implement secure webhook handling.