API reference

fynk API Reference2026-08-25

The fynk API offers a range of endpoints that allow you to build custom integrations against your fynk account.

As far as possible, it uses REST-style, resource-based URLs to allow your applications to interact with the Documents and other entities that make up your fynk account.

Quickstart

Follow these steps to get up and running using the API to work with your fynk account.

1. Create an account

Click here to create a fynk account, or login here if you already have an account.

2. Create a party

Make sure your account contains at least one party. You'll need a party to use in your documents and templates.

3. Create a template

Make sure your account has at least one template available in its template list . You can create a template from scratch or use one from the gallery.

4. Create an API token

Only fynk users with the "Owner" role can perform this step.

Go to the fynk API settings page and click the Create Token button. Give your token a name and give it at least the "Template Reader" role. Feel free to also set an expiry date if you would like to be sure that the token cannot be used later. Then click Create Token and you'll be shown your new API token. Copy the token to your clipboard, and then paste it somewhere safe such a password manager.

For security reasons, we can't show you the API token again after you move past this step, so it's important to note it down somewhere safe that you can refer to later.

5. Try using your API token

You can try out your new API token right from this documentation. Open the page for the Current API token details API endpoint and paste your API token into the Token input in the Auth box, then click Send API Request.

You should then see a JSON response appear, with a data array at the top level containing information about your API token. It should look something like the example below.

{
  "data": {
    "uuid": "efc24626-9724-43cd-9247-e9769fe08844",
    "name": "fynk API token",
    "expires_at": null,
    "account": {
      "uuid": "08fd4c01-7327-42d4-9442-a09dd57f55b8",
      "name": "Demo Inc."
    },
    "settings": {
      "account_default_api_version": "2025-05-22",
      "request_api_version": "2025-05-22",
      "latest_api_version": "2025-06-06",
      "changelog": {}
    },
    "created_at": "2025-07-01T06:19:03Z",
    "updated_at": "2025-07-01T06:19:03Z"
  },
  "links": {
    "documentation": "https://app.fynk.com/v1/docs",
    "document_list": "https://app.fynk.com/v1/api/documents",
    "template_list": "https://app.fynk.com/v1/api/templates"
  }
}

If you instead see a 401 Unauthorized response, make sure you copied the whole of the generated API token, if you think you might be missing part of it, you can revoke the token you created in step 4 and try generating a new token.

6. Try fetching data

Now that you know your API token works, open the page for the List templates API endpoint and try sending that request. You should receive a response like the one below, containing details of the template you created in step three.

At this point, if you would like, you can try altering some of the request parameters like sort_by or sort_direction and re-send the request to see how this affects the response.

You could also copy one of the returned template uuid values and use it to fetch additional information about the template by pasting it into the template input on the Show template page and sending that request.

{
  "data": [
    {
      "uuid": "00ac949f-4871-496f-904c-8703a33fe163",
      "name": "Contract Layout A",
      "locale": "en-US",
      "published": true,
      "signature_type": null,
      "sequential_signing": false,
      "created_at": "2025-05-28T07:11:14Z",
      "updated_at": "2025-05-28T07:11:15Z",
      "archived_at": null,
      "parties": [
        {
          "uuid": "e137ca22-c69d-43ec-bb6b-4b5ebd10417f",
          "reference": "Demo Inc.",
          "entity_name": "Demo Inc.",
          "address": "Am Tabor 36\n1020 Wien",
          "scope": "internal",
          "is_internal_party": true,
          "created_at": "2025-05-28T07:11:14Z",
          "updated_at": "2025-05-28T07:11:14Z"
        },
        {
          "uuid": "9781632f-12b0-4528-bde9-346377f79fe9",
          "reference": "Counterparty",
          "entity_name": null,
          "address": null,
          "scope": "internal_and_external",
          "is_internal_party": false,
          "created_at": "2025-05-28T07:11:14Z",
          "updated_at": "2025-05-28T07:11:14Z"
        }
      ]
      "links": {
        "show": "https://app.fynk.com/v1/api/templates/00ac949f-4871-496f-904c-8703a33fe163"
      }
    },
    // ...

7. Integrate with your systems

You now have a working API token and have seen what an API response looks like. To help you start integrating the API into your systems, take a look at the Request Sample section of any endpoint documentation page. There you can use the menu to select your preferred programming language and see an example of how you could send that endpoint's request using the selected language.

How to create a document from a template

Create a template

Creating a document through the API first requires that your account contains a template to use as the basis of the new document. If you don't have a template available already, you can either create one from scratch or choose one from the gallery and modify it to fit your needs.

Create a document from the template

To create a document from a template, you will need to send a POST request to the Create document from template endpoint. Before you can do this, you will first need to find the UUID of the template you would like to base your new document on.

You can use a filtered request to the List templates endpoint to find the UUID of the template you would like to use. For example, if your template is called "Contract Layout A", a request like this using curl would return a list of the templates matching that name, and you can then take the uuid from the appropriate template in the response:

curl "https://app.fynk.com/v1/api/templates?filter%5Bquery%5D=Contract%20Layout%20A" \
    -H 'Authorization: Bearer <your-api-token>' \
    -H 'Accept: application/json'

The template UUID can then be used as the template_uuid parameter in the Create document from template request. You can optionally provide a name parameter to set the name of the new document - if you don't provide a name, then the new document will be given the same name as the template it is based on.

The request parameters should be sent in a JSON object in the request body. The following example shows how this would look if you wanted to create a document called "Employment Contract" from the template with the UUID "4df1e60a-0114-4dce-89e7-8c5ad397fcf2":

curl -X "POST" "https://app.fynk.com/v1/api/documents/create-from-template" \
    -H 'Authorization: Bearer <your-api-token>' \
    -H 'Accept: application/json' \
    -H 'Content-Type: application/json; charset=utf-8' \
    -d '{"name": "Employment Contract", "template_uuid": "4df1e60a-0114-4dce-89e7-8c5ad397fcf2"}'

Assigning document ownership: you can optionally specify which users from your account should be given ownership of the new document by including the owner_emails parameter in your request. This parameter should contain an array of email addresses belonging to users in your fynk account.

Sending this request will return a JSON response containing the details of the newly created document, which will look something like this:

{
  "data": {
    "uuid": "14e82085-6e94-48c7-9b9b-15bc5c4656d4",
    "name": "Employment Contract",
    "origin": "template",
    // ...
}

The data.uuid returned in the response is the UUID of the newly created document. This would be the value you would need to use in subsequent requests when the endpoint documentation specifies that it accepts a document parameter in the URL (as in the Show document endpoint, for example).

At this point the document has been created and would be visible in the documents list to users with the appropriate permissions.

Populate dynamic fields

If your template contains dynamic fields, your new document will also contain those same dynamic fields, and you can now use the API to customise the content of your document by updating its dynamic field values. The response returned after creating the document will contain a data.dynamic_fields list, which will contain all of the document's dynamic fields and their initial values. This example shows how this could look for a variety of different field types:

{
  "data": {
    "uuid": "14e82085-6e94-48c7-9b9b-15bc5c4656d4",
    // ...
    "dynamic_fields": [
      {
        "uuid": "f4522967-c04f-4113-8762-6d5642c9d863",
        "type": "date",
        "name": "Start of employment",
        "scope": "internal",
        "settings": null,
        "autofill_type": null,
        "format": null,
        "select_values": null,
        "is_mandatory": true,
        "question": "When does the employee start?",
        "question_external": null,
        "value": "2025-10-01",
        "order": null
      },
      {
        "uuid": "4000293a-773b-4efa-ae4b-96bc511d8ad7",
        "type": "text",
        "name": "Job Title",
        "scope": "internal",
        "settings": null,
        "autofill_type": null,
        "format": null,
        "select_values": null,
        "is_mandatory": true,
        "question": "What is the role's job title?",
        "question_external": null,
        "value": "Full-stack Developer",
        "order": null
      },
      {
        "uuid": "c6c0b0bb-87af-44e9-bc8d-0e543b217429",
        "type": "currency",
        "name": "Yearly Gross Salary",
        "scope": "internal",
        "settings": {
          "currencies": [
            "EUR"
          ]
        },
        "autofill_type": null,
        "format": null,
        "select_values": null,
        "is_mandatory": true,
        "question": "What is the role's yearly gross salary?",
        "question_external": null,
        "value": "EUR;75000",
        "order": null
      },
      {
        "uuid": "6778cfe0-1509-47fc-a333-c80c794c0443",
        "type": "select",
        "name": "Location",
        "scope": "internal",
        "settings": null,
        "autofill_type": null,
        "format": null,
        "select_values": [
          "Cork",
          "Dublin"
        ],
        "is_mandatory": true,
        "question": "In which location will the employee be based?",
        "question_external": null,
        "value": "Dublin",
        "order": null
      },
      {
        "uuid": "30e5296d-08fe-4fc8-abd4-df2670583115",
        "type": "bool",
        "name": "Remote work",
        "scope": "internal",
        "settings": null,
        "autofill_type": null,
        "format": null,
        "select_values": null,
        "is_mandatory": true,
        "question": "Does the role allow a remote work component?",
        "question_external": null,
        "value": false,
        "order": null
      }
    ],
    // ...
  }
}

This list of current dynamic field values for a document is also included in the Show document response or can be fetched (without the rest of the document's data) using the List document's dynamic fields endpoint, which also supports filtering the returned list to show only fields that are visible in the rendered document content.

To change the value of a dynamic field, you can use the Update dynamic field endpoint. Looking at the documentation for this, you can see that URL for this request requires a document parameter and a dynamicField parameter. document is the UUID of the document, which you received in data.uuid when creating the document. dynamicField is the UUID of the dynamic field you would like to update, which you can take from the appropriate entry in the document's data.dynamic_fields list.

Using the values from the previous example response, if you wanted to change the value of the "Job Title" field to "Software Engineer", you would take the UUIDs "14e82085-6e94-48c7-9b9b-15bc5c4656d4" for document and "4000293a-773b-4efa-ae4b-96bc511d8ad7" for dynamicField and send a request like this:

curl -X "PUT" "https://app.fynk.com/v1/api/documents/14e82085-6e94-48c7-9b9b-15bc5c4656d4/dynamic-fields/4000293a-773b-4efa-ae4b-96bc511d8ad7" \
    -H 'Authorization: Bearer <your-api-token>' \
    -H 'Accept: application/json' \
    -H 'Content-Type: application/json; charset=utf-8' \
    -d '{"value": "Software Engineer"}'

The format of the value parameter sent in the request body will depend on the type of the dynamic field, the possible types and their corresponding formats are detailed in the Update dynamic field documentation.

Assign metadata

At this point it is also possible to enrich your document with metadata. Your fynk account comes with a selection of reference metadata fields as well as allowing you to create custom account metadata fields. You can assign values for any of these metadata fields to your documents using the API.

Assigning a new metadata value to a document is a two step process:

Use the List metadata endpoint to find the metadata field's UUID.
Send an Add metadata value to document request to create a "metadata value" for that field.

Metadata fields can be scoped to specific document types via their relevant_document_type_uuids property. Use the List document types endpoint to discover the document type UUIDs available in your account when creating or updating metadata definitions.

The List metadata endpoint will return a list of all of the metadata fields that are available in your account. Its response will look something like this:

{
  "data": [
    {
      "uuid": "ddfc1bd7-05c9-456e-9dab-dacfcf44fbb2",
      "type": "system_reference",
      "value_type": "select",
      "name": "end_user_license_type",
      "display_name": "End User License Type",
      "settings": null,
      "select_values": [
        "Freeware",
        "Shareware",
        "Proprietary",
        "Subscription",
        "Open Source",
        "Public Domain",
        "Other"
      ],
      "always_exists": false,
      "description": "The type of license governing the use of the software product."
    },
    {
      "uuid": "7c997428-de84-483b-a072-f2c9da93d924",
      "type": "system_reference",
      "value_type": "currency",
      "name": "freelance_rate",
      "display_name": "Freelance Rate",
      "settings": null,
      "select_values": null,
      "always_exists": false,
      "description": "The hourly rate charged for freelance services."
    },
    {
      "uuid": "205a379c-c4d5-469d-9f67-a025bc630cbf",
      "type": "system_reference",
      "value_type": "number",
      "name": "freelance_hours",
      "display_name": "Freelance Hours",
      "settings": null,
      "select_values": null,
      "always_exists": false,
      "description": "The number of hours to be provided as part of the freelance services."
    },
    // ...
  ]
}

Lets assume that you would like to set the freelance_hours metadata field to 100 for your document. The Add metadata value to document endpoint requires three parameters:

document in the URL: The UUID of the document to add the metadata value to.
metadata_uuid in the request body: The UUID of the metadata field to add the value to.
value in the request body: The value to assign to the metadata field.

Using the values from the previous example responses, this means you would send a request like this:

curl -X "POST" "https://app.fynk.com/v1/api/documents/14e82085-6e94-48c7-9b9b-15bc5c4656d4/metadata-values" \
    -H 'Authorization: Bearer <your-api-token>' \
    -H 'Accept: application/json' \
    -H 'Content-Type: application/json; charset=utf-8' \
    -d '{"value": 100, "metadata_uuid": "205a379c-c4d5-469d-9f67-a025bc630cbf"}'

You would then be able to see the newly set metadata value in data.metadata_values field of the Show document response.

If you need to set or remove values for several metadata fields at once, the Bulk update metadata values endpoint lets you do so in a single request, rather than sending an individual request per field.

Managing parties

At this point, your document may need to have the details of at least one of its parties completed, since your template likely only contains a generic reference to the external party, rather than their concrete details.

List document parties

To see all parties associated with a document, use the List document parties endpoint:

curl "https://app.fynk.com/v1/api/documents/14e82085-6e94-48c7-9b9b-15bc5c4656d4/parties" \
    -H 'Authorization: Bearer <your-api-token>' \
    -H 'Accept: application/json'

is_internal_party in the response tells you whether the party will be editable via the API. Only parties where this field is false can be updated via API. Internal parties can be edited in the settings of your fynk account.

Update party details

You can edit party information using the Update document party endpoint.

For example, to update a party's name and address and set that they are business:

curl -X "PUT" "https://app.fynk.com/v1/api/documents/14e82085-6e94-48c7-9b9b-15bc5c4656d4/parties/ad899fc9-3130-45d5-9cd5-d7a0737f0ffd" \
    -H 'Authorization: Bearer <your-api-token>' \
    -H 'Accept: application/json' \
    -H 'Content-Type: application/json; charset=utf-8' \
    -d '{"entity_name": "BigCo Inc.", "address":"BigCo Plaza, New York"}'

Party management is only allowed while the document is in draft, approved_draft, review, or approved_review stages. Once a document reaches the signing or done stage, parties cannot be updated.

Assign a signatory

Before your document can be signed, you need to assign signatories to it. Signatories are individuals who will sign the document and must belong to one of the document's parties.

To add a signatory to your document, use the Add signatory endpoint. This endpoint requires:

document in the URL: The UUID of the document to add the signatory to
party_uuid in the request body: The UUID of the party this signatory belongs to
email in the request body: The email address of the signatory

You can also optionally provide additional information like first_name, last_name, mobile_phone, and title.

Using the document UUID from our previous examples and assuming you want to add a signatory named "Alex Smith" with email "alex.smith@example.com" to the party with UUID "ad899fc9-3130-45d5-9cd5-d7a0737f0ffd", you would send a request like this:

curl -X "POST" "https://app.fynk.com/v1/api/documents/14e82085-6e94-48c7-9b9b-15bc5c4656d4/signatories" \
    -H 'Authorization: Bearer <your-api-token>' \
    -H 'Accept: application/json' \
    -H 'Content-Type: application/json; charset=utf-8' \
    -d '{
      "party_uuid": "ad899fc9-3130-45d5-9cd5-d7a0737f0ffd",
      "email": "alex.smith@example.com",
      "first_name": "Alex",
      "last_name": "Smith",
      "title": "Software Engineer"
    }'

The response will include the details of the newly created signatory:

{
  "data": {
    "uuid": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
    "party_uuid": "ad899fc9-3130-45d5-9cd5-d7a0737f0ffd",
    "first_name": "Alex",
    "last_name": "Smith",
    "email": "alex.smith@example.com",
    "mobile_phone": null,
    "title": "Software Engineer",
    "profile_photo_url": "https://ui-avatars.com/api/?name=AS",
    "signing_order": 1,
    "has_account_user": false
  }
}

Managing signatories

You can also update signatory information using the Update signatory endpoint, or remove a signatory using the Remove signatory endpoint.

To list all signatories for a document, use the List signatories endpoint.

Some changes to signatories may be prevented while a document is in the signing stage. For example, it is not allowed to remove the only remaining signatory from a party while a document is being signed. If you try to make a modification that is not allowed in the document's current stage, your request will receive a response with a 409 Conflict status.

Setting the signing order

Every signatory is assigned a signing_order as they are added to the document, placing them at the end of the existing order. When the document is signed using sequential signing, this is the order in which their invitations are sent.

To change the order, use the Set signing order endpoint. The request must list the UUIDs of all of the document's signatories, in the order in which they should sign:

curl -X "PUT" "https://app.fynk.com/v1/api/documents/14e82085-6e94-48c7-9b9b-15bc5c4656d4/signatories/order" \
    -H 'Authorization: Bearer <your-api-token>' \
    -H 'Accept: application/json' \
    -H 'Content-Type: application/json; charset=utf-8' \
    -d '{
      "signing_order": [
        "b8f4b8a3-2f19-4f5c-9c27-6f0a1d3ee5b1",
        "a1b2c3d4-e5f6-7890-abcd-ef1234567890"
      ]
    }'

Here the signatory with UUID "b8f4b8a3-2f19-4f5c-9c27-6f0a1d3ee5b1" signs first, and Alex Smith, who was added above, signs second. The order can only be changed before the document is moved to the signing stage.

Granting document access

Signatories are one kind of document user. If you want to give someone access to the document without making them a signatory - for example a collaborator who should review the document, or an additional owner - use the Add document user endpoint.

Move the document to review

At this point, assuming you haven't made any changes to your document outside of the API, it will be in the draft stage. You can use the Move document to review stage endpoint to move the document into the review stage, where you can share it with collaborators:

curl -X "POST" "https://app.fynk.com/v1/api/documents/14e82085-6e94-48c7-9b9b-15bc5c4656d4/stage-transitions/review" \
    -H 'Authorization: Bearer <your-api-token>' \
    -H 'Accept: application/json' \

Move the document to signing

Once you are happy with your document's content, have configured its parties and their signatories, and have added signature blocks to the document for each signatory, you can can use the Move document to signing stage endpoint to move the document into the signing stage:

curl -X "POST" "https://app.fynk.com/v1/api/documents/14e82085-6e94-48c7-9b9b-15bc5c4656d4/stage-transitions/signing" \
    -H 'Authorization: Bearer <your-api-token>' \
    -H 'Accept: application/json' \

This request sends invitations to all document signatories. If sequential signing is enabled, invitations are sent one at a time in the order specified by each signatory's signing_order property, which you can change using the Set signing order endpoint. Otherwise, all signatories receive their invitations simultaneously.

Access the document

Once you have created a document, you can access it in the fynk web application by visiting it from the documents list, assuming your fynk user has the appropriate role and/or team membership. You can also download the document as a PDF via the API, using the data.pdf_url returned by the Show latest revision PDF details endpoint, or directly via the Download latest revision PDF endpoint.

The latter option would look like this using curl to download to a file named my-document.pdf. Note that because the API endpoint returns a HTTP 302 redirect to the actual PDF data, we have to tell curl to follow redirects using the --location flag:

curl "https://app.fynk.com/v1/api/documents/14e82085-6e94-48c7-9b9b-15bc5c4656d4/revisions/latest/pdf/download" \
    -H 'Authorization: Bearer <your-api-token>' \
    --location > my-document.pdf

You can also give people outside your fynk account read access to the document by creating a public link for it via the Create public link endpoint:

curl -X POST "https://app.fynk.com/v1/api/documents/14e82085-6e94-48c7-9b9b-15bc5c4656d4/public-link" \
    -H 'Authorization: Bearer <your-api-token>'

The data.url in the response is the link to share. Treat it like a secret: anyone who has the URL can view the document with it.

How to create a document from a PDF file

Creating a document from a PDF file requires a multi-step upload process to ensure your PDF is safely transferred and processed.

Generate a presigned upload URL

First, you need to obtain an upload URL by making a request to the Create document PDF upload URL endpoint:

curl -X "POST" "https://app.fynk.com/v1/api/file-uploads/document-pdf" \
    -H 'Authorization: Bearer <your-api-token>' \
    -H 'Accept: application/json' \
    -H 'Content-Type: application/json; charset=utf-8'

This will return a response containing the upload details:

{
  "data": {
    "uuid": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
    "url": "https://example-bucket.s3.amazonaws.com/",
    "method": "POST",
    "fields": {
        "key": "tmp/a1b2c3d4-e5f6-7890-abcd-ef1234567890",
        "acl": "private",
        "Content-Type": "application/pdf",
        "policy": "...",
        "X-Amz-Algorithm": "AWS4-HMAC-SHA256",
        "X-Amz-Credential": "...",
        "X-Amz-Date": "20260609T120000Z",
        "X-Amz-Signature": "..."
    },
    "expires_at": "2025-07-29T15:30:00Z"
  }
}

Hold on to the uuid value - you'll need it when you reach the "Create the document" step. The upload URL expires at the time specified in expires_at, so complete the upload promptly.

Upload your PDF file

Using the URL and fields from the previous response, upload your PDF file with a multipart/form-data POST request. Send every entry of data.fields as a form field exactly as provided, then the raw PDF file data (not base64-encoded) in a final file field:

curl -X "POST" "https://example-bucket.s3.amazonaws.com/" \ # use the URL from data.url in the previous response
    -F "key=tmp/a1b2c3d4-e5f6-7890-abcd-ef1234567890" \ # these come from data.fields in the previous response
    -F "acl=private" \
    -F "Content-Type=application/pdf" \
    -F "policy=..." \
    -F "X-Amz-Algorithm=AWS4-HMAC-SHA256" \
    -F "X-Amz-Credential=..." \
    -F "X-Amz-Date=20260609T120000Z" \
    -F "X-Amz-Signature=..." \
    -F "file=@/path/to/your/document.pdf" # the file field must come last

This is a direct upload to an S3-compatible storage bucket using a presigned URL. You do not need to include your fynk API token in the request. Include all fields from the previous response exactly as provided, and send the file field last.

A successful upload returns a 204 No Content response with no body content.

Create the document

Finally, create your fynk document from the uploaded PDF using the Create document from PDF endpoint, providing the uuid from step 1:

curl -X "POST" "https://app.fynk.com/v1/api/documents/create-from-pdf" \
    -H 'Authorization: Bearer <your-api-token>' \
    -H 'Accept: application/json' \
    -H 'Content-Type: application/json; charset=utf-8' \
    -d '{
      "file_upload_uuid": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
      "file_name": "my-contract.pdf",
      "initial_stage": "draft",
      "name": "My Contract from PDF",
    }'

This returns the newly created document:

{
  "data": {
    "uuid": "b71a0628-529f-4ae1-a891-e1c6e9339507",
    "name": "My Contract from PDF",
    "origin": "pdf",
    "stage": "draft",
    // ...
  }
}

Initial stage

The initial_stage may be either draft or done. Here we've used draft, indicating that the document still needs to be signed through fynk. If we'd instead used done this would be the same as the "Import without signing" option in the fynk web interface - the document would be created already in the "Done" stage.

Using a Template

You can specify a template_uuid to copy settings from an existing template. When using template_uuid, various settings (parties, metadata, etc.) will be copied from the template to the new document.

Additional Options

Several optional parameters are available for customizing the document, including team assignment, tags, and AI analysis settings. See the Create document from PDF endpoint documentation for the complete list of available parameters.

What happens next

Your PDF will be processed and converted into a fynk document. If your account has access to AI Analyses, an analysis will be automatically started for the newly created document.

The new document will appear in your documents list and can be managed like any other fynk document through both the web interface and API.

How to store a file in a document's file storage

Storing a file in a document file storage requires a multi-step upload process to ensure your file is safely transferred and processed.

Generate a presigned upload URL

First, you need to obtain an upload URL by making a request to the Create document file storage upload URL endpoint:

curl -X "POST" "https://app.fynk.com/v1/api/file-uploads/document-file-storage" \
  -H 'Accept: application/json' \
  -H 'Authorization: Bearer <your-api-token>' \
  -H 'Content-Type: application/json' \
  -d '{"content_type": "application/pdf"}'

This will return a response containing the upload details:

{
  "data": {
    "uuid": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
    "url": "https://example-bucket.s3.amazonaws.com/",
    "method": "POST",
    "fields": {
        "key": "tmp/a1b2c3d4-e5f6-7890-abcd-ef1234567890",
        "acl": "private",
        "Content-Type": "application/pdf",
        "policy": "...",
        "X-Amz-Algorithm": "AWS4-HMAC-SHA256",
        "X-Amz-Credential": "...",
        "X-Amz-Date": "20260609T120000Z",
        "X-Amz-Signature": "..."
    },
    "expires_at": "2025-07-29T15:30:00Z"
  }
}

Hold on to the uuid value - you'll need it when you reach the "Store the file in a document's file storage" step. The upload URL expires at the time specified in expires_at, so complete the upload promptly.

Upload your file

Using the URL and fields from the previous response, upload your file with a multipart/form-data POST request. Send every entry of data.fields as a form field exactly as provided, then the raw file data (not base64-encoded) in a final file field:

curl -X "POST" "https://example-bucket.s3.amazonaws.com/" \ # use the URL from data.url in the previous response
    -F "key=tmp/a1b2c3d4-e5f6-7890-abcd-ef1234567890" \ # these come from data.fields in the previous response
    -F "acl=private" \
    -F "Content-Type=application/pdf" \
    -F "policy=..." \
    -F "X-Amz-Algorithm=AWS4-HMAC-SHA256" \
    -F "X-Amz-Credential=..." \
    -F "X-Amz-Date=20260609T120000Z" \
    -F "X-Amz-Signature=..." \
    -F "file=@/path/to/your/document.pdf" # the file field must come last

This is a direct upload to an S3-compatible storage bucket using a presigned URL. You do not need to include your fynk API token in the request. Include all fields from the previous response exactly as provided, and send the file field last.

A successful upload returns a 204 No Content response with no body content.

Store the file in the document's file storage

Finally, link your newly uploaded file to the file storage of the document in question using the Store a file in a document's file storage PDF endpoint, providing the uuid from step 1:

curl -X "POST" "https://app.fynk.com/v1/api/documents/{document}/file-storage" \
  -H 'Accept: application/json' \
  -H 'Authorization: Bearer <your-api-token>' \
  -H 'Content-Type: application/json' \
  -d '{
    "file_upload_uuid": "e1413d6e-d516-4f67-84be-6dd98446aebb",
    "file_name": "your-filename.pdf"
  }'

This returns the details of the newly stored file:

{
  "data": {
    "uuid": "09d358a7-4268-413f-a79b-7fed013f8768",
    "sha256": "697651f6ceea8a931289ff64cb62f78ceea5d36f7e84590fe9d5920b2dce52cf",
    "file_name": "your-filename.pdf",
    "file_size": 349059,
    "mime_type": "application/pdf",
  }
}

Core concepts

UUIDs

All resources returned by the fynk API are identified by a UUID. The UUID that identifies a particular resource will always be returned in the uuid field of the resource's JSON representation.

{
  "data" {
    "uuid": "88a774d2-904a-4b1a-9c49-338cdc203041",
    // ...
  }
}

Documents

Documents are the individual contracts, quotes, forms, etc that you are managing through fynk.

Among other things, the API allows you to:

Create new documents
List and search for existing documents
View details of a document
Rename a document or update its general settings
Download a PDF copy of a document
Manage a document's dynamic field and metadata values

Templates

Templates in fynk allow you to create standardized documents efficiently while maintaining flexibility for customization. You can read more about using templates in fynk in our article here.

Using the API you can:

List and search the templates available in your account
View details of a template
Use a template to create a new document

Parties

A party represents a business or natural person who will be involved in a document. Your fynk account will have at least one internal party representing the internal entities relevant to your organization - such as company locations, legal subsidiaries, or departments. Your documents may involve those internal parties, as well as external parties - like suppliers, customers, or partners.

You can read more about managing your account's parties in our article here.

A given party may have one or more signatories in a document.

Using the API you can:

You will also find party information in both documents and templates in their parties fields, which will look something like this:

{
  "data": {
    "parties": [
      {
        "uuid": "e85ce001-529d-4ed3-a320-cf374a2eec7a",
        "reference": "Employer",
        "entity_name": "Demo Inc.",
        "address": "2 Example Street\nLondon\nW1 7PQ",
        "scope": "internal",
        "is_internal_party": true,
        "is_ready_for_signing": false,
        "ready_for_signing_at": null,
        "created_at": "2025-06-03T06:28:54Z",
        "updated_at": "2025-06-03T06:28:54Z"
      },
      {
        "uuid": "ad899fc9-3130-45d5-9cd5-d7a0737f0ffd",
        "reference": "Employee",
        "entity_name": "Jane Marshall",
        "address": "1 Main Street\nBirmingham\nB2 8QR",
        "scope": "internal_and_external",
        "is_internal_party": false,
        "is_ready_for_signing": false,
        "ready_for_signing_at": null,
        "created_at": "2025-06-03T06:28:54Z",
        "updated_at": "2025-06-03T13:05:56Z"
      }
    ]
  }
}

Signature types

The signing process for a fynk document may use one of these signature types:

Simple electronic signature (ses)
Advanced electronic signature, confirmed with a code sent to the signatory's phone (aes)
Advanced electronic signature through a national eID or trust service provider (aes_eid)
Qualified electronic signature (qes)

See our article here for details of the differences between these.

Documents and templates returned by the API have a signature_type field indicating their currently assigned type. If a document does not have a signature type assigned, a type may be specified when moving the document to the signing stage.

aes_eid is only available once it has been enabled in the fynk app's account settings. Signatories then sign with a provider of their choice, never with an in-app code, and each signature records the type it actually achieved: a national eID scheme such as MitID, Swedish BankID or SPID produces an aes signature, while a qualified provider produces a qes one. The type of an individual signature is therefore always ses, aes or qes; aes_eid only ever describes a document or template.

Sequential signing

By default, moving a document to the signing stage invites all of its signatories to sign at the same time. With sequential signing, the signatories are invited one at a time, in ascending order of their signing_order, and each signatory is only invited once the previous one has signed.

A document's sequential_signing value can be set in the following ways:

By creating the document from a template that has sequential_signing enabled - the new document inherits the value from the template
By sending sequential_signing to the Update document endpoint, which is possible up until signing has started
By sending sequential_signing to the Move document to signing stage endpoint, which overrides the document's own value for that signing process, without changing the document's stored value

Sequential signing is always used when a document is signed with the qes or aes_eid signature type, regardless of the document's sequential_signing value.

Signatories are assigned a signing_order as they are added to a document, so the initial order matches the order in which they were added. Use the Set signing order endpoint to change it, which must be done before the document moves to the signing stage.

Document users

Document users are the people who have access to a document. Every document user has exactly one access level, exposed by the API as their role:

owner: Manages the document, including its users. Every document always has at least one owner, and only people with an account user in your fynk account can be owners.
collaborator: Can work on the document.
viewer: Can view the document.

Document users belong to one of the document's parties, indicated by their party_uuid. Specifying a party is required when adding a document user via the API; however, users created through some other means (for example fynk's CRM integrations) may not belong to a party, in which case their party_uuid is null.

Independently of their access level, a document user may also be a signatory, indicated by the is_signatory field. A document user and the corresponding signatory share the same uuid. Note that adding a signatory whose email address is not yet on the document therefore also creates a document user, with the viewer access level.

The API provides endpoints to list, add, update and remove document users.

Warning: Removing a document user revokes their access to the document entirely, including their signatory status. To only remove a user from signing while keeping their access to the document, use the Remove signatory endpoint instead.

Document users are also included in the Show document API response, in its users field:

{
  "data": {
    "users": [
      {
        "uuid": "7f356fd9-5144-4a75-8378-d223bf13011d",
        "first_name": "Jane",
        "last_name": "Marshall",
        "email": "jane@example.org",
        "title": "HR Manager",
        "party_uuid": "e85ce001-529d-4ed3-a320-cf374a2eec7a",
        "has_account_user": true,
        "role": "owner",
        "is_signatory": true
      },
      {
        "uuid": "5cb21e44-3002-4af6-91d4-fe8127cb13d2",
        "first_name": "Liam",
        "last_name": "Roberts",
        "email": "roberts@example.com",
        "title": null,
        "party_uuid": null,
        "has_account_user": false,
        "role": "collaborator",
        "is_signatory": false
      }
    ]
  }
}

Signatories

A signatory represents an individual person who will sign a document. All signatories must belong to a party.

A signatory may be either an internal user, who has an account user in your fynk account, or they may be any other person, who does not have access to your fynk account - e.g. employees of your suppliers, customers, or partners.

Note that signatories for internal parties do not necessarily have to have a fynk account user in your account.

Each signatory is assigned a signing_order when they are added to a document. This determines the order in which signatures are collected when sequential signing is used, and can be changed using the Set signing order endpoint.

You can find signatory information in both the Show document and Show template API responses:

{
  "data": {
    "signatories": [
      {
        "uuid": "7f356fd9-5144-4a75-8378-d223bf13011d",
        "party_uuid": "e85ce001-529d-4ed3-a320-cf374a2eec7a",
        "first_name": "Jane",
        "last_name": "Marshall",
        "email": "jane@example.org",
        "mobile_phone": "+447951123456",
        "title": "HR Manager",
        "profile_photo_url": "https:\/\/ui-avatars.com\/api\/?name=JM",
        "signing_order": 2,
        "has_account_user": true,
      },
      {
        "uuid": "5cb21e44-3002-4af6-91d4-fe8127cb13d2",
        "party_uuid": "ad899fc9-3130-45d5-9cd5-d7a0737f0ffd",
        "first_name": "Liam",
        "last_name": "Roberts",
        "email": "roberts@example.com",
        "mobile_phone": null,
        "title": null,
        "profile_photo_url": "https:\/\/ui-avatars.com\/api\/?name=LR",
        "signing_order": 1,
        "has_account_user": false,
      }
    ]
  }
}

Shareable links

Shareable links let people access a document via a secret URL, without needing a fynk account or receiving an invitation email. Anyone who has the URL can view the document with it, so treat shareable link URLs like secrets.

A document has at most one active public link — a shareable link that is not tied to a specific person. You can manage it via the Show, Create, Update and Delete public link endpoints.

A shareable link can also be tied to a single document user without a fynk account user, identifying that person when they open the document - a personal link. Each document user has at most one active personal link, managed via the Show, Create, Update and Delete personal link endpoints. As a shortcut, you can also create the user and their link in one request by passing invite_method: personal_link to the Add document user endpoint; the link is then returned in the response's personal_link field. Delivering the link to the user is then up to you - fynk sends no invitation email.

Shareable links expire 3 months after creation by default. You can choose a different expiry date - or disable expiration entirely - via the expires_at parameter when creating or updating a link. A link's URL never changes; to invalidate a URL that has been shared too widely, delete the link and create a new one.

Note that shareable links cannot be created while a document is still being drafted (i.e. in the draft or approved_draft stage).

Dynamic fields

Dynamic fields allow your templates and documents to contain dynamically customisable placeholders. To find out how to add dynamic fields to your documents, see our article on using the fynk editor.

Dynamic fields are included in the the Show document and Show template API responses in their dynamic_fields fields.

See this section of the API's How to create a document guide for an introduction to working with dynamic fields via the API.

Conditions

Conditions decide whether a passage of a document applies. A condition is defined in the fynk editor over the document's dynamic fields - for example, a probation period clause that is only part of the contract when an "employment type" field says "permanent". Changing a dynamic field value can therefore change which conditions apply, and with them what the document says.

The API allows you to retrieve a document's conditions, along with whether each one currently applies, via the List document's conditions endpoint. Conditions are read-only over the API: they are created and edited in the fynk editor.

Metadata

In fynk, metadata are details such as dates, financial figures, or contract clauses related to your documents. You can find an overview of how metadata can help in your document management processes in our using metadata article.

The API allows you to retrieve a list of the metadata fields available in your account via the List metadata endpoint, and the Show document and Show template responses each include a metadata_values list, which contain the current metadata values assigned to the respective document or template.

See this section of the API's How to create a document guide for an introduction to working with metadata via the API.

Document types

Document types categorize the documents in your account, e.g. as employment contracts, NDAs, or vendor contracts. Your account comes with a set of system-provided types and may define additional custom types of its own.

The API allows you to retrieve the document types available in your account via the List document types endpoint. The returned uuid values can be used to assign a document type to a document via the Update document endpoint, or to scope metadata fields to specific document types via their relevant_document_type_uuids property.

Authentication

API tokens

To access the API you will need an API token. You can generate new API tokens in your Account Settings, or by asking your account's owner to do this for you if you do not have sufficient permissions.

You will only be able to see a new API token's value one time, immediately after you create it, so make sure to save it.

An API token needs to be sent in the Authorization header of each request. The value of the header should be in the format Bearer <token>, where <token> is the API token itself. For example, if your API token was "WAnMlf6725", your request's Authorization header would look like this:

Authorization: Bearer WAnMlf6725

Tokens created during free trial

If your account is on a Trial plan, you will be able to generate API tokens and use them to make requests to the API for the duration of your trial period. Once your trial ends, you will need to move to a paid plan to continue using the API.

Versioning

The API may change over time. Wherever possible, backwards incompatible changes will only be included in a new "version" of the API, and we will attempt to keep old versions working for a reasonable period after the release of a new version.

Backwards compatibility

New API versions are only released for backwards-incompatible changes. The following changes are considered backwards compatible and will not trigger the release of a new version:

Adding new API endpoints
Adding new optional request parameters to existing API endpoints
Adding new properties to existing responses
Changing the order of properties in existing responses
Adding new variants to enumerated types returned in existing responses, e.g. adding a new DocumentType

Backwards incompatible changes like the following will result in the release of a new version:

Removing existing API endpoints
Adding new mandatory request parameters to existing API endpoints
Removing, renaming or changing the type of properties in existing responses

Setting your Default API Version

When you first visit the API settings page to generate an API token, your account's Default API Version will automatically be set to the current API version. All API tokens you create will use this version by default for API requests.

Updating to new versions

You can update your account's default API version when new versions are released by visiting your Account Settings, where available newer versions will be listed.

Version downgrades are not supported. Once you upgrade to a newer version, you cannot revert to an older version.

To test your integrations against a newer version of the API, without changing your account's default setting, refer to the "Overriding the Default API Version" section on this page.

Overriding the Default API Version

You can override your account's default API version for individual requests by including the Fynk-Api-Version request header. This is useful when testing integrations against newer API versions.

Example: If your account has its default version set to 2025-07-07 and you want to test against version 2025-07-14, include this header:

Fynk-Api-Version: 2025-07-14

Verification: To confirm the version used, check the Fynk-Api-Version header in the API response. This header is included in every response and shows which version processed your request.

Fynk-Api-Version requirements

The version must be valid and available for your account
The version must be the same as or newer than your account's default API version
Requesting an older version will be ignored, and your account's default version will be used instead

Finding available versions: View all available API versions for your account in your Account Settings.

Pagination

Certain endpoints that return a list of resources support pagination. By default, these endpoints will return the first page of their result set with the resources for that page in the data key of the response. The response will include both a links object containing the URLs of other pages and a meta object containing information about the total size of the list.

{
  "data": [
    { /* ... */ },
    { /* ... */ },
  ],
  "links": {
    "first": "https://app.fynk.com/v1/api/documents?page=1",
    "last": "https://app.fynk.com/v1/api/documents?page=2",
    "prev": null,
    "next": "https://app.fynk.com/v1/api/documents?page=2"
  },
  "meta": {
    "per_page": 10,    // maximum number of resources returned in a single page
    "current_page": 1, // the page that was returned in this response
    "last_page": 2,    // the last available page
    "from": 1,         // index of the first item in the current page, starting from 1
    "to": 10,          // index of the last item in the current page, starting from 1
    "total": 17,       // total number of resources available
    "path": "https://app.fynk.com/v1/api/documents"
  }
}

To request the next pages from the result set, you can either use the next link from the returned links object or add a page parameter to the query string of your next request.

You may also control the size of the returned pages by including a page_size parameter in the query string. When an endpoint supports pagination, the page and page_size parameters will be documented in the Query Parameters section of the endpoint's documentation.

Rate Limits

Requests to the API are rate limited based on a rolling one-minute window. If an API token exceeds its rate limit, requests will be rejected with a 429 Too Many Requests response. If this happens, the response will include a Retry-After header indicating how many seconds you should wait before sending any more requests.

The rate limit for the current API token is returned on every response in the X-RateLimit-Limit HTTP header. The number of remaining requests in the current window is returned in the X-RateLimit-Remaining header.

Some endpoints may be subject to stricter limits than the general per-minute limit.

Requests made by Trial accounts may be subject to additional limits.

Webhooks

Webhooks allow you to configure fynk so that it will notify your systems about events that happen in fynk.

Getting started

To setup fynk to send webhooks you'll first need a URL to receive the webhook requests. This will usually be either a dedicated URL on your own systems, or a URL provided by a third party system (e.g. Zapier, Microsoft Teams, Slack, etc). For testing during development, you may wish to use a tool like webhook.site to allow you to inspect various webhook payloads.

The only requirement for the URL handler is that it returns a 20X HTTP status code when it has successfully processed a request. If it returns any other status code, fynk will consider the request failed and attempt to retry it later.

Once you have a URL that you would like to receive the webhook requests, go to the Webhooks page in your account settings and add a new webhook using that URL. If you are integrating with your own systems, you will probably want to leave the "delivery format" and "signature location" options on their default settings.

Only fynk users with the "Owner" role can access the Webhooks settings page.

Now you will need to choose which notification types your webhook should receive. You can do this from your account's Notifications settings page, via the "Edit" option on the relevant notification types.

If you would like different webhooks to be notified based on which template a document was created from, you can override the global notification settings for a particular template by opening the template and editing the settings found in its "Template notifications" tab.

Once you have created a webhook, and configured at least one type of notification to use it, then whenever an event of that type occurs, fynk will send a HTTP POST request to the webhook's URL. See the following sections for details of what the request payload will contain, and how you can verify it was sent by fynk.

Webhook delivery formats

Default delivery format

Webhooks using the "Default" delivery format will receive requests containing a JSON object like this:

{
  "events": [
    {
      "uuid": "05113346-425d-48df-8bf2-a20037fc6fa4",
      "type": "document.moved_to_stage.signing",
      "timestamp": "2026-01-08T14:32:50Z",
      "data": {
        "document": {
          "name": "Employment Contract",
          "uuid": "0a4b6e64-3c4a-4973-af2c-0ec1072b2e1e"
        }
      }
    }
  ],
  "timestamp": "2026-01-08T14:32:59Z"
}

The top-level events field will contain one or more event objects. Each event in the array will have these fields:

Field name	Description
`uuid`	Unique ID for the event
`type`	What kind of event in fynk you are being notified about. The `events` array may contain events of multiple different types
`timestamp`	When the event occurred
`data`	An object containing type-specific data about the event

These are the possible values for the type field:

document.checkpoint.approved
document.checkpoint.canceled
document.checkpoint.rejected
document.comment.created
document.signed_by_all_parties
document.moved_to_stage.signing
document.party.ready_for_signing
document.reminder.cancellation_notice_period
document.reminder.effective
document.reminder.expiring
document.reminder.renewal

Which types of event your webhook actually receives will depend on which Notifications you configure to send to the webhook.

Below you'll find a JSON example showing the structure of each event type. Your webhook handler should parse these from the events array in the payload.

Each example shows a single event object. The actual events array in a webhook delivery may contain multiple events.

document.checkpoint.approved

{
  "uuid": "d445a7e7-d2b7-44c0-87ae-7be2fb2438cd",
  "type": "document.checkpoint.approved",
  "timestamp": "2026-01-13T12:33:53Z",
  "data": {
    "document": {
      "name": "Employment Contract",
      "uuid": "0a4b6e64-3c4a-4973-af2c-0ec1072b2e1e"
    },
    "checkpoint": {
      "uuid": "a833571d-fffe-4b4f-b427-ac04036b56f8",
      "document_stage": "review"
    }
  }
}

document.checkpoint.canceled

{
  "uuid": "2d17653c-6bda-47e3-b51b-2664eb6c8392",
  "type": "document.checkpoint.canceled",
  "timestamp": "2026-01-13T12:32:44Z",
  "data": {
    "document": {
      "name": "Employment Contract",
      "uuid": "0a4b6e64-3c4a-4973-af2c-0ec1072b2e1e"
    },
    "checkpoint": {
      "uuid": "a833571d-fffe-4b4f-b427-ac04036b56f8",
      "document_stage": "review"
    }
  }
}

document.checkpoint.rejected

{
  "uuid": "ccbbb212-d72a-4bb1-a214-db866f45baba",
  "type": "document.checkpoint.rejected",
  "timestamp": "2026-01-13T12:33:13Z",
  "data": {
    "document": {
      "name": "Employment Contract",
      "uuid": "0a4b6e64-3c4a-4973-af2c-0ec1072b2e1e"
    },
    "checkpoint": {
      "uuid": "a833571d-fffe-4b4f-b427-ac04036b56f8",
      "document_stage": "review"
    }
  }
}

document.comment.created

{
  "uuid": "e8880462-bd62-4ff3-8495-6a084c059076",
  "type": "document.comment.created",
  "timestamp": "2026-01-13T10:30:56Z",
  "data": {
    "comment": {
      "type": "comment",
      "uuid": "089d1493-2157-4f73-8077-aa248205af79"
    },
    "document": {
      "name": "Employement Contract",
      "uuid": "0a4b6e64-3c4a-4973-af2c-0ec1072b2e1e"
    }
  }
}

document.signed_by_all_parties

{
  "uuid": "f0c61a22-4deb-4706-8906-097c25e86ed6",
  "type": "document.signed_by_all_parties",
  "timestamp": "2026-01-13T11:48:33Z",
  "data": {
    "document": {
      "name": "Employment Contract",
      "uuid": "0a4b6e64-3c4a-4973-af2c-0ec1072b2e1e"
    }
  }
}

document.moved_to_stage.signing

{
  "uuid": "7a425adc-4a0c-48a8-a5cb-5da162780a27",
  "type": "document.moved_to_stage.signing",
  "timestamp": "2026-01-12T11:46:31Z",
  "data": {
    "document": {
      "name": "Employment Contract",
      "uuid": "0a4b6e64-3c4a-4973-af2c-0ec1072b2e1e"
    }
  }
}

document.party.ready_for_signing

{
  "uuid": "d2925089-ebae-4348-af1c-469760e19d54",
  "type": "document.party.ready_for_signing",
  "timestamp": "2026-01-13T11:52:53Z",
  "data": {
    "party": {
      "uuid": "0ad899fc9-3130-45d5-9cd5-d7a0737f0ffd",
      "reference": "Employee",
      "entity_name": "Jane Marshall"
    },
    "document": {
      "name": "Employment Contract",
      "uuid": "0a4b6e64-3c4a-4973-af2c-0ec1072b2e1e"
    }
  }
}

document.reminder.cancellation_notice_period

{
  "uuid": "75f4d704-8b10-4b68-8ff3-0deb4d46cfcb",
  "type": "document.reminder.cancellation_notice_period",
  "timestamp": "2026-01-13T06:25:15Z",
  "data": {
    "document": {
      "name": "Lease - 1 Oxford Rd",
      "uuid": "756b6deb-4c69-42d0-b416-369710dd24e9"
    },
    "reminder_about_date": "2026-02-13T00:00:00Z"
  }
}

document.reminder.effective

{
  "uuid": "90d9d243-8c5c-4995-9f1f-a3da6b8dde86",
  "type": "document.reminder.effective",
  "timestamp": "2026-01-13T06:36:40Z",
  "data": {
    "document": {
      "name": "Lease - 1 Oxford Rd",
      "uuid": "756b6deb-4c69-42d0-b416-369710dd24e9"
    },
    "reminder_about_date": "2026-02-13T00:00:00Z"
  }
}

document.reminder.expiring

{
  "uuid": "d1d4a218-83bb-46ab-ad8c-758043f0385f",
  "type": "document.reminder.expiring",
  "timestamp": "2026-01-13T06:16:29Z",
  "data": {
    "document": {
      "name": "Lease - 1 Oxford Rd",
      "uuid": "756b6deb-4c69-42d0-b416-369710dd24e9"
    },
    "reminder_about_date": "2026-04-13T00:00:00Z"
  }
}

document.reminder.renewal

{
  "uuid": "5d2e326a-e145-41e3-b23c-639ac4c58f70",
  "type": "document.reminder.renewal",
  "timestamp": "2026-01-13T05:45:00Z",
  "data": {
    "document": {
      "name": "Lease - 1 Oxford Rd",
      "uuid": "756b6deb-4c69-42d0-b416-369710dd24e9"
    },
    "reminder_about_date": "2026-02-13T00:00:00Z"
  }
}

Microsoft Teams delivery format

Webhooks using the "Microsoft Teams" delivery format are intended for use with webhooks created by following these instructions for Workflows for Microsoft Teams, using either the "Send webhook alerts to a channel" or "Send webhook alerts to a chat" workflow template.

Follow the instructions to setup a workflow for the channel or chat of your choice
Take the URL that this gives you and create a new fynk Webhook Target using this URL. The webhook's delivery format must be set to "Microsoft Teams"
Configure one or more Notifications in fynk to use the new webhook

Whenever your selected notifications are triggered, a message desribing the event will be posted to the Teams channel or chat that you selected when setting up your workflow.

Webhook request signatures

When a webhook is created using the default settings, all requests sent to that webhook will include a (Standard Webhooks compatible) signature to allow you to verify that the requests you receive are really sent by fynk.

fynk uses the "Symmetric" signature scheme described here in the Standard Webhooks spec. The signing secret needed to verify received requests is unique per webhook and is available by visiting the Webhooks page in your account settings.

When a webhook uses the default signature location ("Header"), the request ID, signature and timestamp needed for verifying the signature will be included in the headers described in the Standard Webhooks specification (webhook-id, webhook-signature, webhook-timestamp).

If for some reason, you need to receive webhooks in an environment that does not have access to the request headers - and you would still like to verify the requests' authenticity - you can instead set the webhook's signature location to "Query parameter". When you do this, fynk will dynamically include three additional query parameters in the webhook's URL: wh_id (the unique webhook identifier), wh_sig (the signature of the webhook) & wh_ts (the webhook timestamp).

Base URL

All requests use this base URL:

https://app.fynk.com/v1/api

Authentication

AuthorizationstringheaderBearer token

Send Authorization: Bearer <token>, where <token> is your API key or access token.

curl --request GET \
  --url https://app.fynk.com/v1/api/documents \
  --header 'Authorization: Bearer <token>'

Still need help? Share an idea