Fideo's Verify and Signals APIs share the same multi-field request schema. You can pass any combination of identifiers (email, phone, name + address, profile URLs, etc.) in a single payload and the platform will return the richest possible intelligence for that identity.

Minimum viable request

Send at least one email, phone, social handle/ID, or a combined name + postal address. More identifiers dramatically improve both match accuracy and the number of Signals/Verify checks we can evaluate.

High-confidence responses depend on both what you send and how you secure each request:

Multi-field inputs covers every supported field, including hashing requirements, field dependencies (e.g., when names must be paired with postal addresses), platform-specific options like country filters, and guidance on when to send arrays versus single values.
Authorization explains how to provision API keys in ReadMe, authenticate with Authorization: Bearer {API_KEY} headers, rotate secrets, and isolate your sandbox vs. production traffic.

Why a shared payload?

Consistency across products. The MultiFieldReq schema defined in our OpenAPI spec is accepted by both POST /verify and POST /signals, so you only have to build one integration.
Best-match logic. We use deterministic matching when you send exact identifiers (like hashed emails) and probabilistic linking when you provide broader context (like a name plus postal address). Sending multiple identifiers increases match confidence and unlocks more downstream checks.
Optional country filtering. Signals supports request-time countries and excludedCountries lists so you can gate results by geography without changing your Verify implementation.

If you are migrating from FullContact, the payloads are nearly identical. The few Fideo-specific differences are called out in the tables on the following pages.

POC Layout

To optimize the format for a proof of concept, please use the following schema as seen this Excel file: fideo_input_format.xlsx. Mostly this aligns for both Verify and Signals and can extended as necessary.

Supported Columns to provide:

Field Name	Description	Data Type	Constraints	Example
Record_Id	(Optional) Unique identifier for each record	String	Customer ID record ID (Optional)	RCD12345
Email	Primary email address	String	Valid email format. Can be MD5 or SHA256	[email protected]
Phone	Primary phone number	String	Numeric, E.164 format recommended	+1-555-123-4567
First_Name	Given name of the individual	String	Max 100 chars, Alphabetic	John
MIddle_Name	Middle name of the individual	String	Max 100 char, Alphabetic	Quinn
Last_Name	Surname of the individual	String	Max 100 chars, Alphabetic	Doe
Address_Line1	First line of the street address	String	Max 200 chars	123 Main St
Address_Line2	Second line of the street address (optional)	String	Max 200 chars	Apt 4B
City	City of residence	String	Max 100 chars, Alphabetic	Anytown
State_Code	ISO 3166-2 sub-national code or state abbreviation	String	2-3 char code (e.g., CA, NY)	CA
Country_Code	ISO 3166-1 alpha-2 country code	String	2 char code (e.g., US, GB)	US
DOB	Date of birth	Date	YYYY-MM-DD format, Must be a past date	1980-01-15
IP_Address	IP address associated with the record	String	Valid IPv4 or IPv6 format	192.168.1.1
Organization	Name of the organization	String	Max 255 chars	Example Corp
Title	Job title or position	String	Max 100 chars	Software Engineer