RAYNET CRM

RAYNET is a Czech cloud CRM built for sales teams that want the whole cycle in one place: accounts, contacts, leads, deals, tasks, a product catalog, and the offers that come out of it. Two things about this API shape how an agent should work against it, and both are the kind of detail that decides whether a flow is correct or merely plausible.

The first is that RAYNET is configured per instance and most of the interesting fields are ids rather than values. Owner, company, currency, status, and category are all set as ids, and the dictionaries for Users, Currencies, Lead Statuses, Account Categories, Deal Categories, and Product Categories exist so a flow resolves them against this instance instead of carrying numbers copied from somewhere else. Where a field is a fixed enum, it uses the vendor's own wire values rather than friendly text, so account state is A_POTENTIAL, B_ACTUAL, C_DEFERRED, or D_UNATTRACTIVE, account role is A_SUBSCRIBER, B_PARTNER, C_SUPPLIER, or D_RIVAL, deal status is A_DRAFT, B_ACTIVE, D_DONE, E_WIN, F_LOST, or G_STORNO, and task priority is MINOR, DEFAULT, or CRITICAL. Lead statuses and every category are account configurable and resolved through the dictionaries instead. Create and update actions accept an Additional Fields object merged into the request body, so documented RAYNET fields that are not exposed as typed parameters, such as primaryAddress, contactInfo, validFrom, totalAmount, businessCasePhase, or customFields, can still be sent.

The second is worth stating so nothing here is mistaken for more than it is. Offers are read only through this connector: List Offers and Get Offer read what has been quoted, and there is no action that creates or sends one. Products can be listed, read, and created but not updated or deleted. There is no activity object at all in RAYNET's model here, so the activity trail an agent maintains is Tasks, which carry an owner, a deadline, and a priority, and which List Tasks can sweep for work that passed its date without being closed. Operationally, authentication is HTTP Basic using the API Username and API Key, and every request also carries your Instance Name in the X-Instance-Name header. Instance resolution happens before authentication, so a missing header returns HTTP 400 with Instance name or id not present and an unknown instance returns HTTP 404 with Instance not found, both of which arrive before any credential error and are the first thing to check when calls fail. RAYNET uses an unusual verb mapping internally, PUT to create and POST to modify, which the connector handles so you only pick the action. List actions page with offset and limit, defaulting to 50 and capped at 1000, and responses carry totalCount. RAYNET allows roughly 24,000 requests per day and four concurrent connections per client, returning HTTP 429 beyond the daily limit, and more than 20 failed logins in a short window triggers a 60 minute IP block, which is a genuine reason to resolve credentials once rather than retry blindly. This connector ships no triggers. RAYNET documents a webhook subscription API, but the delivered notification payload shape is not published, so a realtime trigger is deferred and there is no webhook action here to register one. Change detection is a scheduled poll on List Accounts, List Deals, or List Tasks sorted on the creation date.