Connect GenderAPI.io V2 with Integrately

Prepare the account and source record

This example enriches Mailchimp records using a name. You need access to the source and destination apps, a GenderAPI.io account key, and the platform features used by the HTTP action. No working credentials or connected accounts are supplied by this guide.

V1 and V2 use the same account key and balance. Verify the key through GET /api/v2/usage before setting up a billable lookup, and check that meta.access.mode is api_key in that endpoint's response. A missing or unrecognized key can fall back to a shared IP trial; it should not silently power a production automation.

Keep the workflow disabled while configuring it. Sending a test prediction still uses normal credits. These instructions were reviewed against public documentation and the V2 contract; an authenticated end-to-end platform workflow was not executed for this publication.

• Authentication and the free usage check →

Configure the GenderAPI.io V2 request in Integrately

• Choose the Mailchimp subscriber trigger and inspect one test record. Keep the audience and subscriber identifiers for the update, select the actual first-name field, and skip records without a name.
• Find Webhook/API and its action to send data to a URL. Before proceeding, inspect the available configuration: the following contract requires authenticated headers and a nested JSON body, whose current editor controls were not independently verified here.
• If the action supports those requirements, select POST and the V2 endpoint below. Set the outgoing request to include Authorization: Bearer YOUR_API_KEY and Content-Type: application/json, using the controls available in your account.
• Build a JSON body with type = name, value = the mapped first name, and options containing ai_mode = off. Verify the chosen action's request preview; a flat form payload is not the V2 JSON body.
• Use the platform's JSON mapping or serialization controls for dynamic names. If the selected action cannot preserve nested JSON or authenticated headers, use an HTTP-capable step rather than putting the key or JSON into query parameters.

Check the JSON body before sending

This is a static input illustration, not a predicted result. First verify the request shape; then replace value with the mapped source field using proper JSON serialization. Do not paste platform mapping expressions into the API as literal strings.

For another input, set type to name, email or username and provide the corresponding value. Add country only when reliable context is available; it is optional and is not a country-of-residence lookup.

{
  "type": "name",
  "value": "Alice",
  "options": {
    "ai_mode": "off"
  }
}

• All request fields, types and defaults →

Inspect the HTTP step before enabling updates

Test one action deliberately and inspect the returned body before selecting downstream fields. Native GenderAPI.io and Webhook/API steps may present different field labels even when the source customer is the same.

Keep the key in the intended connection or request-authentication controls and restrict who can view or share the automation. The public guide does not include a working key, exported connection or preconfigured customer update.

• Integrately Webhook/API actions →
• Integrately documentation →

Route identified, unknown and failed outcomes separately

Parse the response body before choosing a destination update. The JSON paths below refer to the V2 body; your platform may wrap or flatten it. Confirm the actual returned structure with a deliberate test and keep the result attached to the source record ID.

An estimate does not establish a person's identity or self-declared gender. Store it separately from information the person provided. Choose acceptance criteria using evidence for your own workload, and evaluate dataset and AI confidence separately.

• Full V2 response reference →
• Error and retry decisions →

Update only the intended Mailchimp record

Use the saved Mailchimp audience and subscriber identifiers to select the destination record. Add conditions for the result status and billing/access checks below before writing a separate inferred field or approved tag. Never turn a missing or null gender into a default contact category.

Test the identified, unknown and error branches before enabling updates. You can use synthetic sample responses to exercise branch conditions without issuing another prediction. A destination update should be conditional on the checks above, and should not overwrite unrelated fields or tags.

• Response fields and unknown outcomes →
• Accuracy and confidence explained →
• Data sources and the dated database profile →

Control replays and repeated charges

Integrately documents automatic retry behavior, including company-wide controls. Inspect the policy and task history before enabling this automation, and assess other workflows before changing a shared setting. Repeated HTTP lookups are independent billable requests; retain successful output so a later Mailchimp failure can be repaired without another lookup.

Each new GenderAPI request is an independent operation. Deduplicate repeated source events in your own workflow before sending, using a stored source ID and processing state. A source-record ID is not a server-side replay protection key.

A successful unknown is a completed billable result. For a timeout or incomplete response, the result and charge may be unknown; keep the request reference when available and reconcile before resubmitting. Respect Retry-After on rate-limit responses when present.

• Credit and billing states →

Choose when to use AI

forceToGenderize is optional for names, email addresses and usernames. With it enabled, omit ai_mode or use fallback; off and always conflict with it and return 422. A positive starting balance is enough to begin a request even if its final charge takes the balance below zero.

Nickname mode can return a gender with name: null. It can also return an unknown result. Neither ordinary fallback nor nickname inference guarantees a correct or non-null answer.

• AI options and nickname inference →
• Credits and usage →

Validate the workflow before increasing volume

• Verify the real serialized JSON, parsed output paths, API-key access and confirmed billing with one deliberate test. Test unknown and failure routing with fixtures where possible.
• Confirm which workflow steps retry and which customer fields change. Retain the source record ID, completed response and request reference so a later destination failure does not require another lookup.
• Enable a small controlled run and inspect its records and credits before increasing concurrency. GenderAPI credits and the automation platform's task or operation charges are separate.
• For a batch, use POST /api/v2/gender/batch with up to 50 items for API-key access or 10 for the IP trial. The items array can mix names, emails and usernames, with explicit per-item options and unique IDs. Inspect every result; HTTP 200 may contain partial failures. A native connector's batch support must be checked separately.

• Batch mapping and partial failures →
• Python implementation guide →
• Node.js implementation guide →

Frequently asked questions