Send JSON with Insert from URL in FileMaker.

1. Define the request and expected response.

Method: POST
URL: https://api.example.com/contacts
Accept: application/json
Content-Type: application/json
Authentication: Bearer token from $apiToken
Body: JSON text in $requestBody
Expected test response: HTTP 201 with a JSON contact ID

These are practice assumptions, not a real service specification. Check your provider’s required fields, authentication scopes, success codes and duplicate-handling rules before making a request. POST may create a record, so a repeated test can have a lasting effect in the remote system.

2. Build the body as JSON.

Set $requestBody to this calculation. The JSON functions used here require FileMaker Pro 16 or later:

JSONSetElement ( "{}" ;
    [ "name" ; "Maya Chen" ; JSONString ] ;
    [ "email" ; "maya@example.com" ; JSONString ] ;
    [ "sourceId" ; "00042" ; JSONString ]
)

Inspect the result in the JSON formatter. Keep the ID as text and verify the key names. When you substitute real fields, confirm the current record and validate required values before sending.

3. Configure the builder.

Open the cURL builder. Choose POST, enter the example URL, select JSON body and its FileMaker-variable input mode, and enter $requestBody. Configure bearer authentication using variable $apiToken. Do not paste a real token into a shared example.

Set Accept and Content-Type to application/json if they are not already supplied by the chosen body settings. Avoid duplicate conflicting headers. Enable response-header capture into $responseHeaders, use $response as the body target, and set finite connection and total timeouts.

--data-binary @$requestBody

This option tells FileMaker to read the body from the variable. It is a fragment of the generated options, not a complete request or a FileMaker calculation by itself. The builder supplies the surrounding calculation quoting.

4. Recreate the generated guide.

1. Set the body variable before Insert from URL.
2. Set the token variable from your secure configuration.
3. Use the generated URL and cURL-options calculations in their respective dialogs.
4. Keep certificate verification enabled and follow the guide’s URL-encoding setting.
5. Capture FileMaker’s error code and detail immediately after the request.

The output is a reading guide; recreate it in Script Workspace. Clear response variables before each attempt so a failed request cannot be mistaken for a previous successful response. Review the current supported cURL options; a terminal curl command is not interchangeable with a FileMaker request.

5. Confirm the outcome before updating local records.

For this fictional contract, require a successful FileMaker transfer, the final HTTP status 201, and a response containing the expected nonempty contact ID. Another service may return 200, 202 or no body; implement its rules explicitly. A 202 response may require a later status check.

Only after confirmation should you store the remote ID or mark the local record as sent. Keep failure details separate from the success flag. If the remote create succeeds but the local save fails, preserve enough information to reconcile the records.

A timeout is ambiguous: the server may have created the contact before the connection ended. Do not automatically repeat a create request. Use an idempotency key only when the API supports it, or check the remote outcome using the service’s documented lookup mechanism.

• Test a successful request and an invalid required field.
• Test an expired token without changing the request body.
• Test the recovery path for an uncertain outcome.
• Keep tokens and personal data out of logs and screenshots.

Continue reading

• Prepare an API request in FileMaker
• Troubleshoot FileMaker API requests