# Connect GenderAPI.io V2 with Make

> Connect Make to GenderAPI.io V2 for Shopify records. Choose the right connector, send type/value and map data/meta responses, credits and failures.

Canonical HTML: https://www.genderapi.io/blog/make-gender-api-integration

Last reviewed: 2026-09-27

## Choose the Make connection that matches your contract

This guide's HTTP recipe calls GenderAPI.io V2 at https://api.genderapi.io/api/v2/gender. Send type and value in the JSON body; read the estimate from data and the request and billing details from meta. Native connectors have their own contracts, as described below.

Make lists a GenderAPI.io app with name and email actions. Its public listing links to genderapi.io, but does not expose the complete endpoint version or response schema. Inspect the selected module's actual output before mapping existing scenarios.

For explicit V2 behavior, use Make's HTTP app and the request below. The HTTP configuration does not upgrade an existing GenderAPI module; keep working scenarios separate until the replacement has been checked.

- [Make GenderAPI.io app listing](https://www.make.com/en/integrations/gender-api)
- [Existing V1 reference](https://www.genderapi.io/api-documentation/v1)

## Prepare the account and source record

This example enriches Shopify records using an email address. 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](https://www.genderapi.io/docs/v2/authentication#environment-setup)

## Configure the GenderAPI.io V2 request in Make

- Choose the Shopify customer trigger appropriate for your scenario and load a representative test record. Keep the customer ID for the final update and skip records with an empty email.
- Add HTTP > Make a request. In the current HTTP app, choose API key authentication and create a credential with key value Bearer YOUR_API_KEY, placement Header, and parameter name Authorization. Use the credential store rather than putting the key in a URL.
- Set method POST and the URL shown below. Choose application/json for the request body and a data structure with string fields type and value plus an options collection containing the string ai_mode. Set type to email and ai_mode to off; map the customer email into value.
- Enable Parse response. Make's data-structure body serializes mapped values as JSON, so names or addresses containing quotes do not require hand-built string concatenation.

| HTTP setting | Value | Purpose |
| --- | --- | --- |
| `Method` | `POST` | Submit one prediction request. |
| `URL` | `https://api.genderapi.io/api/v2/gender` | The GenderAPI.io V2 single-prediction endpoint. |
| `Authorization` | `Bearer YOUR_API_KEY` | Replace the placeholder using the platform's authentication/header controls. |
| `Content-Type` | `application/json` | Send an object with a nested options object, not form fields. |
| `options.ai_mode` | `off` | A deliberate dataset-only first test; normal charge is 1 credit, even if unknown. |

## 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.

**Make request to GenderAPI.io V2**

```json
{
  "type": "email",
  "value": "alex@example.com",
  "options": {
    "ai_mode": "off"
  }
}
```

- [All request fields, types and defaults](https://www.genderapi.io/docs/v2/request-parameters)

## Inspect the HTTP step before enabling updates

Keep redirects disabled for this fixed HTTPS API destination. When changing between Make HTTP app versions, review the authentication and body settings again; their controls can differ.

Run one deliberate test, inspect the parsed response bundle, and create separate routes for accepted identified results, unknown results and operational failures before adding the customer update.

- [Make HTTP app configuration](https://apps.make.com/http)
- [Make API-key credentials and header placement](https://apps.make.com/api-key-authentication-type)
- [Make automatic retries](https://help.make.com/automatic-retry-of-incomplete-executions)

## 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.

| Check | Expected value or type | Workflow decision |
| --- | --- | --- |
| `meta.access.mode` | api_key for this account workflow | Stop on ip_trial; correct the key. A successful trial response does not prove account authentication and may already have used trial credits. |
| `meta.usage.billing_status` | confirmed or unconfirmed | If unconfirmed, retain the request ID and seek billing reconciliation before retrying or proceeding. |
| `data.result_status / data.gender` | identified with male or female; unknown with null | Route accepted identified results to a separate inferred field. Preserve unknowns without assigning a default category. |
| `data.confidence / data.confidence_kind` | number from 0 to 1 or null; evidence kind or null | Interpret observed_frequency and model_reported separately; neither is a universal accuracy guarantee. |
| `data.source / data.sample_count` | dataset, ai or none / integer or null | Retain how the estimate was obtained. AI has no stored sample count; a dataset count is not a product accuracy score. |
| `meta.request_id / meta.usage` | request reference / usage object | Store with your workflow record and result. Keep API keys and unnecessary personal input out of routine logs. |
| `HTTP failure / missing response` | Problem Details or no complete response | Pause the update and inspect error and billing state. A timeout does not prove that the server did no work. |

- [Full V2 response reference](https://www.genderapi.io/docs/v2/responses)
- [Error and retry decisions](https://www.genderapi.io/docs/v2/errors-and-retries)

## Update only the intended Shopify record

In the parsed HTTP response, map the V2 body paths below. Make may place the body beneath a module output label; select the nested data and meta objects from the inspected bundle. Update only the customer ID saved by the trigger, using a separate inferred field or tag policy.

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](https://www.genderapi.io/docs/v2/responses)
- [Accuracy and confidence explained](https://www.genderapi.io/accuracy-methodology)
- [Data sources and the dated database profile](https://www.genderapi.io/data-provenance)

## Control replays and repeated charges

Review Make's error handlers and incomplete-execution settings. Some temporary errors can be retried even without an explicit Retry handler. A retry of the HTTP module can submit another billable lookup. If the lookup succeeded and a later Shopify update failed, reuse the saved lookup output when repairing that update.

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](https://www.genderapi.io/docs/v2/credits-and-usage)

## 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.

| Request option | Behavior | Credits for a successful lookup |
| --- | --- | --- |
| options.ai_mode: off | Use the dataset only. | 1, including an unknown result |
| options.ai_mode: fallback | Try the dataset, then ordinary AI when no gender is returned. This is the single-request default. | 1 total, including AI fallback |
| options.ai_mode: always | Ask AI directly. | 2 |
| forceToGenderize: true | Try the dataset first, then allow AI to interpret a personal nickname or alias even without a real given name. | 1 for a resolved dataset result; 2 total if AI is used |

- [AI options and nickname inference](https://www.genderapi.io/docs/v2/ai-options)
- [Credits and usage](https://www.genderapi.io/docs/v2/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](https://www.genderapi.io/docs/v2/batch)
- [Python implementation guide](https://www.genderapi.io/integrations/python)
- [Node.js implementation guide](https://www.genderapi.io/integrations/javascript)

## Should I paste the API key into Make's URL?

No. For the V2 HTTP recipe, store Bearer YOUR_API_KEY in an HTTP API-key credential, with Header placement and Authorization as the parameter name. The POST endpoint does not accept a key query parameter.

## Does the direct HTTP example allow AI?

The first-request body sets options.ai_mode to off. Change it deliberately to fallback for ordinary AI fallback at 1 credit total, or always for AI at 2 credits. forceToGenderize tries the dataset first and costs 1 credit if resolved there or 2 total when AI is used.

## Is an unknown result free, or safe to retry automatically?

No. A successful unknown is billable and complete. A replay is a new operation. For transport errors or unconfirmed billing, inspect the returned usage and request reference before deciding whether to resubmit.

## Was this workflow executed in a connected account?

No. The platform setup instructions were reviewed against public documentation on 26 September 2026. The GenderAPI.io V2 request and response explanations were reviewed on 27 September 2026. Test the chosen action's current fields, authentication, body, response and retries in your own account before enabling production updates.

## Reference sources

- [Make GenderAPI.io app listing](https://www.make.com/en/integrations/gender-api)
- [Make HTTP app configuration](https://apps.make.com/http)
- [Make API-key credentials and header placement](https://apps.make.com/api-key-authentication-type)
- [Make automatic retries](https://help.make.com/automatic-retry-of-incomplete-executions)
- [GenderAPI.io V2 request contract](https://www.genderapi.io/docs/v2/request-parameters)
- [GenderAPI.io V2 response contract](https://www.genderapi.io/docs/v2/responses)
- [GenderAPI.io V2 billing and credits](https://www.genderapi.io/docs/v2/credits-and-usage)