Fipto Travel Rule API

The Travel Rule API from Fipto — 1 operation(s) for travel rule.

Operations 1

PATCH /companies/{company_id}/beneficiaries/{beneficiary_id}/wallet-details/travel-rule Update the travel rule of a beneficiary #

Work with this as data

Every API here is available over the APIs.io API and to AI agents over MCP.

MCP server

One button, every client — Claude, Cursor, VS Code and the rest.

https://apis.io/mcp

Tools for apis

7 MCP tools reach this
  • find_apisBrowse and filter every API in the catalog.
  • get_api_artifactsOne API's artifacts, grouped by type.
  • get_openapiThe primary OpenAPI for this API.
  • find_similar_apisAPIs that look like this one.
  • apis_io_searchSTART HERE — APIs, providers and tags for one query, each with its total.
  • resolveTurn a domain, URL or GitHub org into the provider it belongs to.
  • find_cohortsEvery scored population of providers in the catalog.
All 92 tools →

Call it yourself

curl for this page
This API
curl "https://apis.io/api/v1/apis/fipto-travel-rule-api"
All apis
curl "https://apis.io/api/v1/apis?limit=25"

Discovery needs no key. Ratings and market analysis are Pro.

Get an API key

Free tier, no form to fill in. Signing in shares your email address with us — we store it to create your key and to recognise you if you sign in with another provider. See our Privacy Policy and Terms.

A second provider on the same verified email joins the account you already have.

OpenAPI Specification

fipto-travel-rule-api-openapi.yml Raw ↑
openapi: 3.2.0
info:
  title: Fipto - OpenAPI 3.0 Travel Rule API
  version: 4.3.0
  description: This is a REST API specifications based on OpenAPI 3.0 for Fipto solution.
  contact:
    url: https://www.fipto.com/
servers:
- url: https://api.fipto.app
  description: The API server on production
tags:
- name: Travel Rule
paths:
  /companies/{company_id}/beneficiaries/{beneficiary_id}/wallet-details/travel-rule:
    patch:
      summary: Update the travel rule of a beneficiary
      operationId: updateBeneficiaryTravelRule
      description: Update the travel rule of a beneficiary.
      tags:
      - Travel Rule
      parameters:
      - $ref: '#/components/parameters/company_id'
      - $ref: '#/components/parameters/beneficiary_id'
      requestBody:
        content:
          application/json:
            schema:
              type: object
              required:
              - data
              properties:
                data:
                  $ref: '#/components/schemas/beneficiary_travel_rule_patch_data'
      responses:
        '200':
          description: Beneficiary travel rule successfully updated.
          content:
            application/json:
              schema:
                allOf:
                - $ref: '#/components/schemas/meta'
                - type: object
                  properties:
                    data:
                      $ref: '#/components/schemas/beneficiary_travel_rule_patch_data'
components:
  schemas:
    meta:
      description: Metadata of the request
      type: object
      required:
      - meta
      properties:
        meta:
          type: object
          required:
          - request_id
          properties:
            request_id:
              oneOf:
              - $ref: '#/components/schemas/uuid'
              - $ref: '#/components/schemas/request_id'
            query_parameters:
              $ref: '#/components/schemas/query_parameters'
    data_default:
      description: Fields required on all objects.
      type: object
      required:
      - type
      - attributes
      properties:
        type:
          type: string
        attributes:
          type: object
          minProperties: 1
    request_id:
      type: string
      pattern: '[0-9]-[0-9a-fA-F]{8}-[0-9a-fA-F]{24}'
      description: Request identifier.
    beneficiary_travel_rule_patch_data:
      description: Beneficiary information used to modify a Beneficiary
      allOf:
      - $ref: '#/components/schemas/data_default'
      - type: object
        properties:
          type:
            type: string
            default: beneficiary_travel_rule
          attributes:
            $ref: '#/components/schemas/beneficiary_travel_rule'
    vasp_name:
      type: string
      description: Allow alphanumeric, +, -, _, &, (, ), °, ., ;, space, single quote, comma, and all accented characters.
      pattern: ^[a-zA-Z0-9À-ɏ\s+'()_&,°.;-]*$
    beneficiary_travel_rule_custodial:
      description: Custodial travel rule information.
      type: object
      oneOf:
      - properties:
          vasp_name:
            $ref: '#/components/schemas/vasp_name'
          vasp_did:
            type: string
            pattern: ^did:[a-zA-Z0-9]*:.*$
            example: did:ethr:0x123456789abcdef
        required:
        - vasp_did
      - properties:
          vasp_name:
            $ref: '#/components/schemas/vasp_name'
          vasp_website:
            type: string
            format: url
        required:
        - vasp_website
        - vasp_name
    uuid:
      type: string
      pattern: '[0-9a-fA-F]{8}\b-[0-9a-fA-F]{4}\b-[0-9a-fA-F]{4}\b-[0-9a-fA-F]{4}\b-[0-9a-fA-F]{12}'
      description: 128-bit value used to uniquely identify an object.
      example: 123e4567-e89b-12d3-a456-426614174000
    travel_rule_non_custodial:
      description: Non custodial travel rule information.
      type: object
      required:
      - is_self_hosted
      properties:
        is_self_hosted:
          type: boolean
          enum:
          - true
    query_parameters:
      description: Information about the parameters in the request. All query string parameters provided (or implicit/with default value) will be returned
      type: object
    beneficiary_travel_rule:
      description: Travel rule data linked to a beneficiary
      oneOf:
      - $ref: '#/components/schemas/beneficiary_travel_rule_custodial'
      - $ref: '#/components/schemas/travel_rule_non_custodial'
      - type: object
        readOnly: true
        additionalProperties: false
  parameters:
    company_id:
      name: company_id
      in: path
      required: true
      description: The Company ID given by Fipto.
      example: 9de0691c-bc8d-409b-8f40-75d4f45db2f3
      schema:
        $ref: '#/components/schemas/uuid'
    beneficiary_id:
      name: beneficiary_id
      in: path
      required: true
      description: The Beneficiary ID given by Fipto.
      example: 0967e211-93c9-481f-978a-182eef29c80a
      schema:
        $ref: '#/components/schemas/uuid'
x-topics:
- title: Authentication
  content: "# Getting Started\n\nBefore using the API you need to generate a private/public key pair using:\n\n    openssl genrsa -out private-key.rsa 2048\n    openssl pkcs8 -topk8 -inform PEM -outform PEM -nocrypt -in private-key.rsa -out private-key.pem\n    openssl rsa -in private-key.rsa -pubout -out public-key.pem\n\nAfter sending us the public key by email, you will receive an api key, referred below as `keyId`.\n\n## HTTP request signing\n\nAll authenticated requests must include the following headers:\n\n- `Host`: target host of the request, e.g. \"api.fipto.app\"\n- `Date`: time of creation of the request, in RFC1123 format\n- `Signature`: signature of the request (see below)\n\nIn addition, requests with a body (POST, PUT, PATCH) must include:\n\n- `Content-Type`: MIME type of the body, e.g. \"application/json\"\n- `Digest`: base64-encoded SHA-256 hash of the body, in the format SHA-256=<hash>\n\n`Date` values are expected to be earlier than the present time, but not\nearlier than 1 minute.\n\n`Digest` values must obviously match to the actual hashes of their request\nbodies. The way of getting the digest is language-dependent but a basic\nUNIX approach would be\n\n    echo -n $BODY | openssl dgst -sha256 -binary | openssl enc -base64 -A\n\nwhere $BODY contains the string representation of the request body.\n\n### Signature header\n\nRequests are signed and verified using the [HTTP signatures protocol](https://datatracker.ietf.org/doc/html/draft-cavage-http-signatures-12).\nLibraries exist in different languages for building signed requests using that\nprotocol. We focus here on our specific requirements.\n\nWe expect the authentication data to be present in a `Signature` header.\n\nThe \"signing string\" itself should contain all the headers mentioned in the previous section,\nas well as the `(request-target)` pseudo-header (see [section 2.3](https://datatracker.ietf.org/doc/html/draft-cavage-http-signatures-12#section-2.3)).\n\nFor example, the signing string of a POST request would look like:\n\n    (request-target): post /companies/c240e5bf-863e-4f44-91aa-cc74a8b3303f/wallets\n    host: api.demo.fipto.tech\n    date: Fri, 24 Jan 2025 08:56:30 GMT\n    content-type: application/json\n    digest: SHA-256=X48E9qOokqqrvdts8nOJRJN3OWDUoyWxBf7kbu9DBPE=\n\nThat string must then be signed using the RSA-256 algorithm, encoded in base64 and\nincluded in the `signature` field of the header.\n\nThe following constraints apply to other fields:\n\n- the `keyId` field must contain the UUID of your API user\n- the `headers` field must contain `(request-target)` as well as all the headers mentioned above\n- the `algorithm` field must be \"hs2019\" (or its synonym \"rsa-sha256\")\n\nThe final header of a POST request should look like:\n\n    Signature: keyId=\"<uuid of your api user>\",algorithm=\"hs2019\",headers=\"(request-target) host date content-type digest\",signature=\"<base64-encoded signature>\"\n"