Skip to content

HTTP API

Everything you send to Fidero goes through one endpoint – the same one the browser SDK posts to. Your servers post to it directly, for what happens away from the browser: an overnight renewal, a payment webhook, an upgrade recorded in your CRM.

You don’t need a library. Anything that can make an HTTP request can send events.

The endpoint

Section titled “The endpoint”
POST /v1/t

The base URL is https://api.datahappy.co. Requests are JSON (Content-Type: application/json), carry one event each and are capped at 100 KB. There’s no batch endpoint – send events as they happen.

Fidero responds as soon as the event is accepted. Enrichment, formatting and delivery happen after acceptance – How the pieces fit traces an event through all three.

Authentication

Section titled “Authentication”

Every request authenticates with your project’s API token, sent in the body as authToken. The token is provisioned with your project – keep it in your server’s environment, not in source control.

A missing or invalid token returns 401.

The event envelope

Section titled “The event envelope”

A complete request:

Terminal window
curl https://api.datahappy.co/v1/t \
  -H "Content-Type: application/json" \
  -d '{
    "authToken": "YOUR_API_TOKEN",
    "projectId": "YOUR_PROJECT_ID",
    "type": "track",
    "event": "subscription_renewed",
    "userId": "user_8f3a91",
    "properties": {
      "transaction_id": "inv_7Rt2M4",
      "value": 29.99,
      "currency": "GBP"
    },
    "messageId": "inv_7Rt2M4",
    "channel": "server"
  }'
authToken string required

Your project’s API token.

projectId string required

The ID of the project the event belongs to.

type string required

The kind of message. Always track for sending events.

event string required

The event name. Use a standard name, such as subscription_renewed or purchase_completed, so mapping is decided for you.

userId string

The user’s ID in your system. This is how the event joins its person’s profile – and picks up the attribution and identity Fidero holds for them.

anonymousId string

The visitor’s Fidero anonymous ID. Pass it for conversions that can fire before a user ID exists.

properties object

The event’s properties: value, currency, transaction_id, items and the rest.

context object

Metadata around the event. From your servers, traits is usually the only field to set.

traits object

User traits to set on the profile, such as email or name.

channel string

Where the event originated: server, web or mobile. If omitted, events sent directly to the API are treated as server.

timestamp string

When the event happened, as an ISO 8601 string. Defaults to when the event arrives. Future timestamps are clamped to arrival time.

messageId string

A unique ID for the event, used for deduplication. For conversions, set it to the transaction_id, so the same conversion reported from browser and server shares one ID.

Property names, the items[] array and user traits are on Data schema. Event names are on Standard events.

Responses

Section titled “Responses”

A successful request returns 200, and the body is the JSON string "OK":

200 OK
"OK"

Errors share one shape – an error object with an id and a message:

Error
{
  "error": {
    "id": "3f8c2a1e-9b47-4d2e-8a1f-5c6d7e8f9a0b",
    "message": "An internal error occurred. Please provide this ID to support: 3f8c2a1e-9b47-4d2e-8a1f-5c6d7e8f9a0b"
  }
}
Status Meaning
200 Accepted – enrichment and delivery follow
400 The request body isn’t valid JSON
401 authToken missing or invalid
500 Something failed on Fidero’s side – quote the error.id to support
Section titled “Related”
Sending server events Worked examples: Stripe renewals, webhooks and CRM triggers.
Data schema Every event property, item field and user trait Fidero recognises.
Connecting anonymous → server Link conversions that happen before a user ID exists.

The platform overview covers the architecture behind the enrichment – why the server holds each customer’s context at all.