If Swym does not have a native integration with your marketing platform, CRM, or internal system, you can use webhooks to receive Swym events directly in your system.
A webhook allows Swym to automatically send real-time event data (such as wishlist activity or back-in-stock subscriptions) to an endpoint URL that you provide.
This is ideal for:
Custom-built CRMs
Internal data warehouses
Middleware platforms
Marketing automation tools without a native Swym integration
Any third-party tool that supports receiving HTTP requests
Prerequisites
You must be on the Enterprise plan to configure webhooks.
You must have access to a secure server endpoint that can receive HTTP requests over HTTPS.
⚠️ Webhook configuration is not self-serve.
To enable webhooks, you must contact [email protected].
How Setup Works
Since webhook configuration is managed by the Swym team, you will need to share the following details with us:
Your webhook Endpoint URL (must support HTTPS)
HTTP Method (POST recommended / GET supported)
Authentication Header name (e.g., Authorization, X-API-Key)
Authentication Scheme (e.g., Bearer, Basic, Token, ApiKey)
Authentication Prefix (if required)
Once we receive this information:
Our team will configure the webhook on your account.
We will confirm once setup is complete.
You can then begin receiving events in your system.
For setup, please email: [email protected]
How It Works
A shopper performs an action (e.g., adds an item to a wishlist or subscribes to a back-in-stock alert) or a product state changes (price drop/ stock replenished, etc).
Swym captures that event.
Swym sends the event data to your configured HTTPS webhook endpoint.
Your system receives the payload and processes it (e.g., triggers an email, updates a CRM record, logs data, etc.).
Endpoint Requirements
To ensure reliable and secure delivery, your endpoint must meet the following requirements:
1. HTTPS Required
Your webhook endpoint must:
Support HTTPS
Have a valid SSL certificate
This ensures data is securely transmitted between Swym and your system.
2. Supported HTTP Methods
POST (recommended)
GET (supported if required)
POST is preferred because it securely sends structured JSON data in the request body.
3. Idempotency Handling
Your endpoint must be able to handle duplicate event deliveries safely.
While Swym retries only when necessary, temporary failures may cause the same event to be delivered more than once. Your system should:
Detect duplicate events (using event ID or timestamp)
Avoid processing the same event multiple times
4. Retry Logic
If your endpoint does not return a success response, Swym will retry delivery:
Up to 5 retry attempts
Using exponential backoff (increasing delay between retries)
Response Codes & Retries
Return 2xx (e.g., 200, 201) → Event is marked successful and no retries will occur
Return 4xx or 5xx → Swym will treat the delivery as failed and retry the request
To prevent unnecessary retries, your endpoint should return a 2xx response as soon as the event is successfully received.
Authentication Support
Swym supports sending authentication credentials via HTTP headers.
When reaching out to support, please specify:
Header name
Authentication scheme
Token value
Prefix format (if applicable)
Common Header Types
Header Name | When to Use |
Authorization | Most common industry standard |
X-API-Key | When API key must be passed as a custom header |
X-Auth-Token | Some legacy or custom APIs |
Authentication Schemes (Prefix Formats)
Some APIs require a prefix before the token value.
Scheme | Example Header |
Bearer | Authorization: Bearer <token> |
Basic | Authorization: Basic <base64-encoded-credentials> |
Token | Authorization: Token <token> |
ApiKey | Authorization: ApiKey <token> |
(No prefix) | X-API-Key: <token> |
If your API requires a custom format, please include full details when contacting support.
Supported Events
Swym currently supports the following event categories for webhooks:
Payload Structure & Customization
The default event payload includes structured key–value pairs (as documented in the links above).
However, we can adjust the payload structure to match your system requirements, including:
Modifying key names
Changing field order
Including or excluding specific fields (subject to feasibility)
If you need the payload customized, please contact: [email protected]
We’ll review your requirements and confirm compatibility before enabling the webhook.
Best Practices
To ensure smooth operation:
Always return a 2xx response quickly once the event is received
Process heavy business logic asynchronously on your side
Log incoming webhook events for debugging
Monitor endpoint uptime and failure rates
If you're unsure whether webhooks are the right solution for your use case, reach out to our support team and we’ll help guide you to the best integration approach.