com.temsor/api

Tools

• bic_validate

  Checks a SWIFT/BIC against ISO 9362 structure (8 or 11 characters), splits bank/country/location/branch, and names well-known institutions. Payment files reject a BIC that is the wrong length or uses a forbidden character in the location code long before they care which bank it is. This checks the ISO 9362 pattern, flags test BICs (a 0 in the location code), and treats XXX as the primary office. A handful of well-known 8-character bank codes resolve to a name; anything else returns bankName null rather than a guess. This is not a lookup in the SWIFT directory. A structurally valid BIC can still be unissued, deactivated or mistyped by one letter that still fits the pattern.

  shallow
• container_validate

  Validates an ISO 6346 freight-container number: owner code, category letter, serial and check digit. Bills of lading and terminal scans mistype container numbers constantly; the check digit (ISO 6346) catches almost all of those before a customs filing. The fourth letter is the category (U freight, J equipment, Z chassis, R reefer). Owner codes are not resolved to a company — BIC's owner-code register is a separate paid product. A valid number is arithmetically self-consistent, not proof the box exists.

  shallow
• creditor_ref

  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.

  shallow
• email_verify

  Checks an e-mail address: syntax, whether the domain can actually receive mail, disposable and role-account detection, and typo correction. No SMTP probing. Most competitors connect to the target server and try RCPT TO, which sounds thorough but produces a confident-looking number you cannot trust: most servers are catch-all, the big providers refuse to answer, and doing it in bulk gets the probing IP blacklisted. We report only what is provable — whether the domain has a mail exchanger, whether it is a known disposable service, whether the mailbox belongs to a role rather than a person, and whether the domain looks like a typo of a common one (gmial.com → gmail.com). Addresses are also normalised, so Gmail dots and +tags stop creating duplicate signups.

  shallow
• eu_vat_rates

  Dated EU-27 VAT rates (standard, reduced, super-reduced, parking) plus the Union OSS threshold. Not a goods classification. Invoice software that hard-codes “Germany is 19%” breaks the day a member state moves a rate, and it never knew the reduced list. This is a point-in-time schedule of published rates for the EU VAT area, keyed by country and asOf. It is a schedule of rates, not which goods fall in which reduced band — there is no HS or NACE mapping. Great Britain, Northern Ireland, Switzerland, Norway and Türkiye are recognised and returned with null rates. If the table has no row for that date the rates are null; the last known line is not reused.

  shallow
• eu_vat_validate

  Validates an EU VAT number against the official VIES register, with per-country format checks and honest handling of upstream outages. VIES is free but unreliable: member-state services drop out individually and a failed lookup can easily be mistaken for a rejection. Treating an outage as "invalid" means charging VAT to a customer who should have been exempt — an error with a price tag. So this endpoint never returns `invalid` when the service could not answer; it returns `unknown` and names the reason, and reports whether that country's service is currently up. Format is checked locally first, so an obvious typo never becomes an upstream call. Results are cached for 24 hours. Note that most member states do not publish the company name; when they do, it is returned.

  shallow
• iban_validate

  Validates an IBAN from any of 70+ countries: checksum, country length and in-country account structure, and resolves the bank and branch codes. Most free libraries stop at the mod-97 checksum. That only says the digits are self-consistent — not that the number could exist in that country. This checks the country's BBAN structure too, so a wrong-length or wrong-shaped account is rejected before your payment file reaches the bank. When only the two check digits are wrong, the correct ones are computed and returned as a suggestion, because that is what people actually mistype. Turkish, Dutch and Belgian IBANs additionally resolve to a bank name when the national code is in our table; otherwise bankName is null. This is not a SWIFT directory.

  shallow
• id_mrz

  Parses ICAO 9303 TD1/TD3 MRZ and verifies check digits — format check, not identity proof. Machine-readable zones on passports and ID cards carry ICAO 9303 check digits (weights 7,3,1). This parses TD3 (2×44, typical passport) and TD1 (3×30, typical ID card) and reports each field check. A mismatched check digit is HTTP 200 with valid:false — the string is still an MRZ, just inconsistent. This is a format check, not identity proof: it does not confirm the document was issued or that the holder is who they claim.

  shallow
• isin_validate

  Validates an ISIN (ISO 6166): country code, national identifier and the letter-aware check digit. Portfolio imports and corporate-action files fail on a single mistyped ISIN. The check digit is a Luhn variant that first expands letters to two digits (A=10…Z=35), so a swapped letter is caught, not just a swapped digit. XS (international), EU and other reserved prefixes are accepted as country codes even though they are not ISO 3166 territories. A valid ISIN is self-consistent. It is not proof the security exists, is listed, or is the one you meant.

  shallow
• lei_lookup

  Looks up a Legal Entity Identifier in the GLEIF register: legal name, registration status, country, and BIC. Checksum-valid is not the same as currently registered — a LAPSED or MERGED LEI still passes ISO 7064. This endpoint checks the digits locally first (a typo never becomes an upstream call) then GET the GLEIF lei-records API. Results are cached for 24 hours. GLEIF allows 60 requests per minute; above that, or on timeout/5xx, we return `unknown` rather than invent a registration. HTTP 404 means the service answered and the LEI is not in the index (`invalid`). This is not a replacement for GLEIF’s own API for bulk. `status` is registration.status (ISSUED/LAPSED/MERGED/…), not entity.status (ACTIVE).

  shallow
• lei_validate

  Validates a 20-character Legal Entity Identifier (ISO 17442) with the ISO 7064 mod-97 check digits. KYC and MiFID reporting reject an LEI that fails the check digits before anyone looks the entity up. The algorithm is the same family as IBAN (ISO 7064 mod 97-10) over all 20 characters; the remainder must be 1. The first 4 characters are the issuing LOU prefix, the next 14 the entity, the last 2 the check digits. This does not call GLEIF. A checksum-valid LEI can be lapsed, merged, or never issued. Use GLEIF's free API if you need "this legal entity is currently registered".

  shallow
• mcp_index

  Searchable, dated archive of what every public MCP server actually exposes — tool definitions, daily change feed, and rug-pull detection. The official MCP registry publishes a server’s name and address but not its tool surface; the only way to learn what a server exposes is to connect and call `tools/list`. This endpoint does that daily across every public remote server and keeps the result. Three things become answerable that the source cannot answer: tool-level search (the registry has none), uptime, and — the one that matters for security — what a tool’s description said yesterday. In MCP a tool description is part of the context handed to the model, so it is prompt text; if it changes after the user approved the server, the server has silently injected new instructions. Each indexed tool also carries a review score with the matched evidence, so the claim can be checked rather than trusted. Measurement boundary: only `initialize` and `tools/list` are ever called — never `tools/call`.

  shallow
• model_archive

  Dated archive of LLM prices, context windows, announced retirement dates and quiet delistings across 400+ models and 50+ providers. Providers overwrite their pricing pages and drop models from their catalogs without publishing what changed. This endpoint keeps a daily record, so three otherwise unanswerable questions become answerable: what a model cost on a given date (a contract and budget question), which models were quietly removed (a dependency-audit question), and when a retirement date was first announced and whether it later moved (a migration-planning question). Price points land in the shared time series, so a full range query is available through `series/history` under `model.price.<provider>/<model>.<input|output|cache_read>`. The archive can only accumulate forward — it cannot be reconstructed after the fact.

  shallow
• model_drift

  Independent daily record of what changed behind a provider endpoint: which alias resolved to which model, and when behaviour shifted. Providers update models behind stable endpoint names. This endpoint publishes an independent measurement: a fixed probe suite is sent daily at temperature 0, three repeats per probe, and the identity a provider declares in its own response (`modelVersion`, `system_fingerprint`, region) is recorded alongside. A change is only reported as drift when the repeats agree with each other and disagree with the previous run — same-day disagreement is noise, not drift. `aliases` answers "what was actually behind `gemini-flash-latest` on that day"; a question that cannot be answered retroactively.

  shallow
• pay_epc_qr

  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.

  shallow
• phone_validate

  Validates and normalises a phone number to E.164, classifies the line type, and resolves the province for Turkish landlines. For signup and checkout flows that need to store one canonical form and reject typos early. Turkish numbers are handled in depth: landline area codes resolve to a province, mobile and special ranges (toll-free 0800, fixed-rate 0850, premium 0900) are classified, and every accepted input comes back in both E.164 and national notation. One thing this endpoint deliberately does not claim: the current mobile operator. Turkey has had number portability since 2008, so a 0532 number may well be on another network today. Competing APIs report the prefix owner as "the operator" and customers pick SMS routes on that basis. We return it as `originallyAllocatedTo` with the caveat attached, because a confident wrong answer costs more than an honest gap.

  shallow
• sanctions_screen

  Screens a name against six official sanctions lists — US OFAC, UN, EU, UK OFSI, Switzerland SECO and Canada — with transliteration-aware fuzzy matching. Six official lists are reduced to one schema, so a name is checked everywhere at once instead of six integrations. Cyrillic and Arabic names are transliterated, titles and corporate suffixes are stripped, and known spelling families are unified — "Abd al-Rahman", "Abdul Rahman" and "Abdulrahman" reach the same record. Every hit explains itself: which name matched, whether it was an alias the source flags as weak, and how the birth year and country compared. Supply `birthYear` whenever you have it; it removes most false positives. `asOf` screens against the lists as they stood on a past date, which is the question auditors actually ask — note that this is bounded by when our archive begins, reported in `coverage`.

  shallow
• series_history

  Returns the accumulated history of public data series with change statistics and a source receipt for every point. Currently ingesting the Turkish Central Bank daily FX bulletin (`tcmb.usd`, `tcmb.eur`, …), normalised to one unit so JPY-style 100-unit quotes stop biting. Leave `seriesId` empty to list the catalogue. `fillGaps` carries the last value across weekends and holidays; `includeEvidence` attaches the source URL and content hash for every point, so a value can still be defended years later.

  shallow
• shipping_identify

  Identifies which carrier a tracking number belongs to, validates it where a checksum exists, and returns the canonical tracking link. Built for order systems that receive numbers from many carriers and have to route the customer to the right tracking page. Turkish carriers mostly use plain numeric ranges that overlap, so a single confident answer is often impossible — this returns a ranked candidate list instead of inventing certainty, because sending a customer to the wrong carrier's page makes them think the parcel is lost. Universal Postal Union (S10) numbers are fully verified: the mod-11 check digit is computed, the service type and origin country are decoded. For formats whose checksum we have not verified against the standard, the result says `not-verified` rather than guessing — a wrong rejection is worse than an honest unknown. Delivery status is deliberately out of scope: Turkish carriers require merchant credentials for that, and scraping their sites would be fragile and against their terms.

  shallow
• tin_validate

  Validates a tax identifier for 25+ countries: checksum where the algorithm is public, format-only where it is not. Country is required. Onboarding forms collect a tax number from whatever country the customer is in and then store garbage because they only checked the length. This applies the published checksum (SIREN/SIRET Luhn, ABN mod-89, CPF/CNPJ, NIP, BSN 11-proef, NIF/NIE, OIB, IČO, AFM, TCKN/VKN, …) and refuses to guess the country: the same 9 digits are a well-formed identifier in more than one place. Where the checksum is not published (US EIN, UK UTR, DE Steuernummer, IN PAN) the answer is format + `checksum: not-verified`, not a fake pass. This does not ask any tax authority whether the number is issued.

  shallow
• tr_address_parse

  Splits a free-form Turkish address into neighbourhood, street, building, floor, flat, district, province and postcode. Handles the abbreviation chaos (Mah./Mh., Cd./Cad., Sk./Sok., No:12/5, K:3 D:7), cross-checks the province against the postcode, repairs misspelled district names against a dictionary, and returns a confidence score. Anything it could not place is listed in `unparsed` — nothing is dropped silently. Built for shipping, checkout and CRM systems that receive Turkish addresses typed by humans.

  shallow
• tr_business_days

  Adds business days or counts them between two dates, accounting for Turkish public and religious holidays including half-day eves. Ramadan and Sacrifice feasts follow the Hijri calendar and cannot be derived reliably by formula, so announced dates are read from a table; years without an official announcement are returned with `confirmed:false` rather than guessed silently. For delivery promises, SLA clocks, payment terms and shipping estimates.

  shallow
• tr_fuel_prices

  Petrol, diesel and heating-oil pump prices for all 81 Turkish provinces, including the price in force on any past date. The distributor publishes today's pump price and a per-district history query, one district and one range at a time. This endpoint answers the question that actually costs money, in a single call: what was diesel in Ankara on 12 March? Pass `asOf` for the price in force on that day — if the distributor did not change prices that day, the previous price is carried forward and `effectiveFrom` says when it started, with `carriedForward: true`. Pass `from`/`to` to get the change events in a window, each with the percentage move. Every figure carries the source URL and a content hash of the page it was read from, so the number can still be defended in an audit years later. Leave `province` empty to list coverage.

  shallow
• tr_invoice_build

  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.

  shallow
• tr_invoice_parse

  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.

  shallow
• tr_labor

  Computes Turkish severance (kıdem), notice (ihbar) and annual-leave entitlement from service dates and the gross wage, using the official ceiling and minimum-wage tables for the given day. Payroll and HR tools in Turkey chase a parameter that changes every January and July: the severance ceiling, the SGK cap, the minimum wage. This endpoint applies the statutory formulae (Labour Law 4857 arts. 17 and 53, former 1475 art. 14) to those tables. The ceiling is applied to the monthly wage, not the total. Stamp tax (0.759%) is deducted from severance; income tax is not — kıdem is exempt. Notice pay IS taxable; we return the gross and say so, because the actual withholding depends on the employee's cumulative tax base. What this will not tell you: whether the employee is entitled to severance at all. That depends on the reason for termination (retirement, just cause, marriage, military service…). Treating the number as "what is owed" is how you lose at trial.

  shallow
• tr_money_to_words

  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.

  shallow
• tr_tebligat_clock

  Computes the deemed-received date and the HMK deadline (with holiday shifting) for a Turkish notification, from the date the underlying event actually happened. Turkish notification law (7201) ties the deadline clock to an event that is not "the date on the letter" — for electronic notification the UETS platform reports send, read AND reached dates, and only the reached date starts the clock (art. 7/a: deemed received 5 calendar days after reaching the address, whether or not it was opened). HMK adds two more rules on top: the day of notification itself does not count (art. 92 — the period starts the next day) and if the computed last day lands on a weekend or a full public/religious holiday, it moves to the next business day (art. 93); a half-day eve (arife) does not shift it. What this will not tell you: whether the notification was itself valid, or what a specific `periodType` (itiraz, temyiz, cevap…) is in days for your case — that number differs by statute and we do not guess it; supply `periodDays` yourself. Only the "hmk" law family is covered so far.

  shallow
• tr_validate

  Validates Turkish national ID, tax number, IBAN, licence plate, IMEI, barcodes, KEP address and MERSİS number from one endpoint, with type auto-detection. Goes past a yes/no: resolves the bank behind an IBAN, the province behind a licence plate and the GS1 country prefix behind a barcode. Pure local computation — no upstream service is called, so latency is microseconds and the answer never changes for the same input.

  shallow
• tr_vat

  Splits a Turkish amount into net, VAT and (optionally) withholding: who pays the seller, who remits the withheld VAT. For invoice lines and checkout totals that have to show KDV dahil / hariç and, when the parties are in a withholding (tevkifat) situation, the split between what the buyer pays the seller and what the buyer remits to the tax office. Rates are 0, 1, 10 and 20 percent. Withholding is a fraction of the VAT (2/10 through 10/10), or a named code from the GİB partial-withholding list. The 2026 threshold (TRY 12,000 gross) is reported and compared with the amount, but `applies` is always null: whether withholding actually applies depends on the taxpayer status of both parties, which this endpoint does not know. Feeding it a fraction is not a legal opinion.

  shallow
• vin_validate

  Validates a 17-character VIN: forbidden letters, ISO 3779 check digit, WMI region/manufacturer, model year and plant. Typos in a VIN are usually a forbidden letter (I, O, Q — they look like 1 and 0) or a shifted character. This rejects those, splits WMI/VDS/VIS, and names the manufacturer when the WMI is in a conservative built-in table. The 9th-character check digit is computed and compared, but a mismatch does not fail the VIN: it is mandatory under FMVSS 115 in North America and routinely ignored in Europe. `checkDigitMatch` tells you; `valid` stays true if the 17-character form is legal. This does not decode the full vehicle (engine, body, options) and does not prove the VIN was issued.

  shallow

Embed this server’s score

Tool count and median score across every tool in this server’s corpus — honest in a way a single cherry-picked tool’s badge wouldn’t be.

[![Vouch score](https://vouch.tools/api/servers/913a22e7-43c0-4934-b664-2fdbd8aeef68/badge.svg)](https://vouch.tools/servers/913a22e7-43c0-4934-b664-2fdbd8aeef68)