Finance

Part of the catalogue. The same key, envelope and billing cover every other endpoint too.

RF Creditor Reference · EPC QR Payload · Build Turkish IBAN · Turkish e-Invoice Builder · Turkish e-Invoice (UBL-TR) Parser · Amount to Turkish Words · Turkish FAST / TR Karekod Payload

No account needed to try any endpoint on this page.
Deterministic endpoints answer from cache in single-digit milliseconds.
Every response carries a receipt: credits charged, cache status, duration.

Free try on this page → when you need a key, Proceed to pay · API access.

Try free Proceed to pay · API access Read the spec

POST/v1/finance/creditor-ref

Request

{
  "reference": "RF18 5390 0754 7034"
}

no request sent yet

Response

Press Run to try free — no key needed.

7endpoints

—data points banked

—time series

—median response

Why this exists

Built for hostile input

A Turkish address arrives as "Cd." or "Cad." or "Caddesi", with the flat number glued to the building number. Generic parsers drop half of it silently. This one tells you what it could not place.

Every number carries its provenance

Each archived point stores the source URL and a content hash of the page it came from, and the archive is committed to a Merkle root anchored in Bitcoin. Every commitment — with its cutoff, leaf count and anchors — is published at /proof, so you can check for yourself how current the latest one is. The bulletins themselves are public and anyone can read them; what this adds is that a number you quote can be shown to be the number we held on that date, and that it has not been edited since.

You only pay for work

Repeated inputs come from cache and cost zero credits. If a response ever fails its own schema, the call is refunded automatically.

Endpointsexpand any row to see the parameters and call it live

Finance7

/v1/finance/creditor-ref RF Creditor Reference deterministic 1 credit

Validates or generates an ISO 11649 RF creditor reference (mod-97 check digits).

SEPA credit transfers carry an RF creditor reference so remittance data survives the payment chain. The check digits are the same ISO 7064 mod-97 used for IBAN: RF and the two digits move to the end, letters become 10–35, remainder must be 1. If the input already starts with RF and two digits it is validated; otherwise a 1–21 character alphanumeric payload is encoded. A bad checksum is rejected with 400 — a self-inconsistent reference must not enter a payment file.

Parameters

reference*

string

ISO 11649 RF creditor reference, or a 1–21 character payload to encode.

POST/v1/finance/creditor-ref

Request

{
  "reference": "RF18 5390 0754 7034"
}

no request sent yet

Response

Press Run to try free — no key needed.

/v1/pay/epc-qr EPC QR Payload deterministic 1 credit

Builds an EPC069-12 v3.1 V2 (002) SCT payload. Does not send money; returns text only, no PNG.

European payments often start from a QR that encodes an EPC069-12 credit-transfer payload. This endpoint builds that text in version 002 (V2): BCD, UTF-8, SCT, optional BIC, name, electronic IBAN, EUR amount. Purpose and structured remittance are left empty; unstructured remittance is copied if given. Lines are LF, not CRLF. IBAN spaces are stripped and letters uppercased; mod-97 is not required here. TRY, USD and any non-EUR currency are rejected. This does not send money and does not render a QR image.

Parameters

name*	string	Beneficiary name (SCT Name).
iban*	string	Beneficiary IBAN, with or without spaces.
amountEur*	number	Transfer amount in EUR (positive).
remittance	string	Unstructured remittance (e.g. invoice number).
bic	string	Beneficiary BIC; optional in V2 (002).
currency	string	Must be EUR if provided. Other currencies are rejected.

POST/v1/pay/epc-qr

Request

{
  "name": "Franz Mustermänn",
  "iban": "DE71110220330123456789",
  "amountEur": 12.3,
  "remittance": "RF18539007547034"
}

no request sent yet

Response

Press Run to try free — no key needed.

/v1/tr/iban/build Build Turkish IBAN deterministic 1 credit

Builds a Turkish IBAN from a 5-digit bank code and account number, computing ISO 7064 check digits.

A Turkish IBAN is TR + 2 check digits + 5-digit bank code + 1 reserved digit + 16-character account. This pads the account on the left, defaults the reserved digit to 0, computes the mod-97 check digits, and resolves the bank name from the same national table used by IBAN validation when the code is known. Unknown bank codes still produce a structurally valid IBAN with bankName null — existence at the bank is not claimed.

Parameters

bankCode*	string	5-digit Turkish national bank / EFT code (e.g. 00062).
accountNumber*	string	Account number, up to 16 alphanumeric characters (padded left with zeros).
reserved	string	Reserved BBAN digit after the bank code. Defaults to 0.

POST/v1/tr/iban/build

Request

{
  "bankCode": "00062",
  "accountNumber": "0000005197864578"
}

no request sent yet

Response

Press Run to try free — no key needed.

/v1/tr/invoice/build Turkish e-Invoice Builder 3 credits

Builds a UBL-TR e-Invoice or e-Archive XML document from plain JSON, computing every total and validating the parties.

Selling into Türkiye means issuing a UBL-TR document whose element order is fixed by schema and whose totals must agree to the kuruş, or the integrator rejects it. This endpoint takes the invoice as ordinary JSON and returns the XML. Totals you send are ignored on purpose — line amounts, per-rate VAT subtotals and the payable amount are all recomputed here, because a rounding difference of one kuruş is the most common rejection. VKN and TCKN checksums are verified, and the amount is written out in Turkish words as invoices require. It does not sign the document and does not transmit it: the financial seal and the submission to the tax authority belong to your certificate and your integrator. What comes back is a document ready to enter that step.

Parameters

profile	"TEMELFATURA" \| "TICARIFATURA" \| "EARSIVFATURA"	TEMELFATURA: no formal objection flow. TICARIFATURA: buyer may accept/reject. EARSIVFATURA: buyer is not an e-Invoice user. default "TEMELFATURA"
invoiceTypeCode	"SATIS" \| "IADE"	default "SATIS"
id	string	Invoice number. Omit and supply `series` to have it built from the series and sequence.
series	string	Three-letter series code, used with `sequence`.
sequence	integer	Sequence number within the series and year.
uuid	string	Document UUID (ETTN). Generated when omitted.
issueDate*	string
issueTime	string
currency	string	ISO 4217. Anything other than TRY requires `exchangeRate`. default "TRY"
exchangeRate	number	Units of TRY per one unit of `currency`.
supplier*	object
customer*	object
lines*	object[]
notes	string[]	default []
amountInWords	boolean	Adds the payable amount written out in Turkish words as a note, the way invoices require. default true
despatchDocumentId	string	Delivery note number, if the goods shipped separately.
orderReferenceId	string

POST/v1/tr/invoice/build

Request

{
  "series": "ABC",
  "sequence": 123,
  "issueDate": "2026-07-26",
  "supplier": {
    "name": "Örnek Yazılım A.Ş.",
    "taxNumber": "4840847211",
    "taxOffice": "Kadıköy",
    "street": "Moda Cad.",
    "buildingNumber": "12",
    "district": "Kadıköy",
    "city": "İstanbul"
  },
  "customer": {
    "name": "Alıcı Ticaret Ltd. Şti.",
    "taxNumber": "3250566341",
    "taxOffice": "Beşiktaş",
    "city": "İstanbul"
  },
  "lines": [
    {
      "name": "Yazılım geliştirme hizmeti",
      "quantity": 10,
      "unitCode": "HUR",
      "unitPrice": 1500,
      "vatRate": 20
    }
  ]
}

no request sent yet

Response

Press Run to try free — no key needed.

/v1/tr/invoice/parse Turkish e-Invoice (UBL-TR) Parser deterministic 3 credits

Turns a UBL-TR e-Invoice or e-Archive XML document into clean JSON: parties, line items, taxes and totals.

Works regardless of the namespace prefix the sender used (cbc:, cac:, ns0:), normalises single-line documents into arrays, and reports amount mismatches in `warnings` instead of returning quietly wrong totals. The job that costs accounting and expense software the most engineering time.

Parameters

xml*

string

UBL-TR e-Invoice / e-Archive (e-Arsiv) XML body.

POST/v1/tr/invoice/parse

Request

{
  "xml": "<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<Invoice xmlns=\"urn:oasis:names:specification:ubl:schema:xsd:Invoice-2\"\n         xmlns:cbc=\"urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2\"\n         xmlns:cac=\"urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2\">\n  <cbc:UBLVersionID>2.1</cbc:UBLVersionID>\n  <cbc:ProfileID>TEMELFATURA</cbc:ProfileID>\n  <cbc:ID>ABC2026000000123</cbc:ID>\n  <cbc:UUID>3f2504e0-4f89-11d3-9a0c-0305e82c3301</cbc:UUID>\n  <cbc:IssueDate>2026-07-20</cbc:IssueDate>\n  <cbc:InvoiceTypeCode>SATIS</cbc:InvoiceTypeCode>\n  <cbc:DocumentCurrencyCode>TRY</cbc:DocumentCurrencyCode>\n  <cac:AccountingSupplierParty><cac:Party>\n    <cac:PartyIdentification><cbc:ID schemeID=\"VKN\">1234567890</cbc:ID></cac:PartyIdentification>\n    <cac:PartyName><cbc:Name>Örnek Yazılım A.Ş.</cbc:Name></cac:PartyName>\n    <cac:PostalAddress><cbc:StreetName>Moda Cad.</cbc:StreetName><cbc:BuildingNumber>12</cbc:BuildingNumber>\n      <cbc:CitySubdivisionName>Kadıköy</cbc:CitySubdivisionName><cbc:CityName>İstanbul</cbc:CityName></cac:PostalAddress>\n    <cac:PartyTaxScheme><cac:TaxScheme><cbc:Name>Kadıköy</cbc:Name></cac:TaxScheme></cac:PartyTaxScheme>\n  </cac:Party></cac:AccountingSupplierParty>\n  <cac:AccountingCustomerParty><cac:Party>\n    <cac:PartyIdentification><cbc:ID schemeID=\"VKN\">9876543210</cbc:ID></cac:PartyIdentification>\n    <cac:PartyName><cbc:Name>Alıcı Ticaret Ltd. Şti.</cbc:Name></cac:PartyName>\n  </cac:Party></cac:AccountingCustomerParty>\n  <cac:TaxTotal><cbc:TaxAmount currencyID=\"TRY\">200.00</cbc:TaxAmount>\n    <cac:TaxSubtotal><cbc:TaxableAmount currencyID=\"TRY\">1000.00</cbc:TaxableAmount>\n      <cbc:TaxAmount currencyID=\"TRY\">200.00</cbc:TaxAmount><cbc:Percent>20</cbc:Percent>\n      <cac:TaxCategory><cac:TaxScheme><cbc:Name>KDV</cbc:Name><cbc:TaxTypeCode>0015</cbc:TaxTypeCode></cac:TaxScheme></cac:TaxCategory>\n    </cac:TaxSubtotal></cac:TaxTotal>\n  <cac:LegalMonetaryTotal>\n    <cbc:LineExtensionAmount currencyID=\"TRY\">1000.00</cbc:LineExtensionAmount>\n    <cbc:TaxExclusiveAmount currencyID=\"TRY\">1000.00</cbc:TaxExclusiveAmount>\n    <cbc:TaxInclusiveAmount currencyID=\"TRY\">1200.00</cbc:TaxInclusiveAmount>\n    <cbc:PayableAmount currencyID=\"TRY\">1200.00</cbc:PayableAmount>\n  </cac:LegalMonetaryTotal>\n  <cac:InvoiceLine>\n    <cbc:ID>1</cbc:ID>\n    <cbc:InvoicedQuantity unitCode=\"C62\">10</cbc:InvoicedQuantity>\n    <cbc:LineExtensionAmount currencyID=\"TRY\">1000.00</cbc:LineExtensionAmount>\n    <cac:TaxTotal><cbc:TaxAmount currencyID=\"TRY\">200.00</cbc:TaxAmount>\n      <cac:TaxSubtotal><cbc:TaxableAmount currencyID=\"TRY\">1000.00</cbc:TaxableAmount>\n        <cbc:TaxAmount currencyID=\"TRY\">200.00</cbc:TaxAmount><cbc:Percent>20</cbc:Percent>\n        <cac:TaxCategory><cac:TaxScheme><cbc:Name>KDV</cbc:Name><cbc:TaxTypeCode>0015</cbc:TaxTypeCode></cac:TaxScheme></cac:TaxCategory>\n      </cac:TaxSubtotal></cac:TaxTotal>\n    <cac:Item><cbc:Name>Yıllık Lisans</cbc:Name></cac:Item>\n    <cac:Price><cbc:PriceAmount currencyID=\"TRY\">100.00</cbc:PriceAmount></cac:Price>\n  </cac:InvoiceLine>\n</Invoice>"
}

no request sent yet

Response

Press Run to try free — no key needed.

/v1/tr/money/to-words Amount to Turkish Words deterministic 1 credit

Writes a monetary amount out in Turkish words, the way invoices, cheques and promissory notes require.

Applies the rules that trip up generic libraries: Turkish says "bin", never "bir bin"; the kuruş part is read separately; and both "1.234,56" and "1,234.56" are accepted and told apart automatically. A mandatory field on Turkish e-invoices, cheques and notes — with no off-the-shelf API until now.

Parameters

amount*	string \| number	Amount. Accepts both "1.234,56" and 1234.56.
currency	"TRY" \| "USD" \| "EUR" \| "GBP"	default "TRY"
style	"lower" \| "title" \| "upper"	Output letter case. default "lower"
wrapHash	boolean	default false

POST/v1/tr/money/to-words

Request

{
  "amount": "1.234,56"
}

no request sent yet

Response

Press Run to try free — no key needed.

/v1/tr/pay/qr Turkish FAST / TR Karekod Payload deterministic 1 credit

Builds a person-to-person TR Karekod (FAST) payment payload from IBAN, name and optional TRY amount. Text only — no PNG.

Turkish instant payments (FAST) can start from a TR Karekod that encodes the payee IBAN and name in EMV-style TLV. This builds the person-to-person organisation (payload format indicator 750210): application template with IBAN, payee name, optional 12-digit kuruş amount, optional free-text explanation, and a CRC-16/CCITT-FALSE trailer. The Turkish IBAN is normalised and checked with ISO 7064 mod-97; non-TR IBANs and non-TRY currencies are rejected. This does not send money and does not render a QR image.

Parameters

iban*	string	Beneficiary Turkish IBAN (with or without spaces).
name*	string	Payee name shown to the payer (2–26 chars after trim).
amount	number	TRY amount; omitted → static QR (payer enters amount).
explanation	string	Optional remittance note (application free field 10).
currency	string	Must be TRY if provided.
generatorCode	string	QR generator / EFT code (4 digits). Defaults to last 4 of the IBAN bank code.

POST/v1/tr/pay/qr

Request

{
  "iban": "TR33 0006 1005 1978 6457 8413 26",
  "name": "Ali Yilmaz"
}

no request sent yet

Response

Press Run to try free — no key needed.

Pricingone key covers every endpoint

Free try on this page → when you need a key, Proceed to pay · API access.

Proceed to pay · API access All plans →

Credits are consumed per call and cache hits are free. Requests without a key run on a narrow per-IP demo quota so you can evaluate before signing up.

The API key is e-mailed the moment payment clears. Upgrades keep the same key, so your integration is never broken.

Want to finish the integration before paying?

Use it from an AI assistantthe same catalogue, exposed as MCP tools

Every endpoint is also published over the Model Context Protocol, so Claude, ChatGPT or your own agent can call it directly — no glue code, no wrapper functions. The assistant sees the same input schemas and the same metering.

Currently 68 tools. New endpoints appear automatically; nothing to update on your side.

claude_desktop_config.json

{
  "mcpServers": {
    "temsor": {
      "url": "https://api.temsor.com/mcp",
      "headers": { "x-api-key": "fk_live_…" }
    }
  }
}

Quickstart

Official client: npm install temsor-api · npmjs.com/package/temsor-api

Node.js

import Client from "temsor-api";

const api = new Client({ apiKey: KEY });
const r = await api.${(() => {
  const first = apis[0];
  return first.slug.split(/[/-]/).map((p, i) => (i === 0 ? p : p[0].toUpperCase() + p.slice(1))).join('');
})()}(${esc(JSON.stringify(apis[0].examples[0]?.input ?? {}))});
console.log(r, r.$meta);

cURL

curl -s https://api.temsor.com/v1/finance/creditor-ref \
  -H "content-type: application/json" \
  -H "x-api-key: fk_live_…" \
  -d '{"reference":"RF18 5390 0754 7034"}'

JavaScript

const res = await fetch("https://api.temsor.com/v1/finance/creditor-ref", {
  method: "POST",
  headers: { "content-type": "application/json", "x-api-key": KEY },
  body: JSON.stringify({"reference":"RF18 5390 0754 7034"})
});
const { data } = await res.json();

Python

import httpx
r = httpx.post("https://api.temsor.com/v1/finance/creditor-ref",
    headers={"x-api-key": KEY},
    json={"reference":"RF18 5390 0754 7034"})
data = r.json()["data"]