Is Powerlink the same as Fireberry?

Yes - Powerlink rebranded to Fireberry, while the API host remains api.powerlink.co.il and some documentation still sits under the older domain. Searching either name returns partially relevant material, so do not treat code as outdated merely because it says Powerlink, nor as current merely because it says Fireberry.

How does the Fireberry API authenticate?

With a tokenid taken from system settings - the gear icon, then Integration, then API Forms, where a "My Token" field appears. Critically, every user has their own unique token, so the token you use determines both what the integration can see and who its actions are attributed to.

Why should a Fireberry integration use a dedicated user?

Because the token is tied to a person. Using an employee's token means every record the integration creates is attributed to them, distorting performance reporting, and their permissions silently limit what the integration can see. Worst of all, if that employee leaves and the account is deactivated, the integration stops - typically months after launch, when nobody remembers the dependency.

How do you read data from the Fireberry API?

Through a POST to a query endpoint rather than a GET with query-string parameters, which surprises anyone arriving from classic REST. You build a filter payload as an object instead of a string. Plan pagination from the start - a query that returns everything works fine against a test account and falls over on a production one.

How do you avoid duplicate records when pushing leads into a CRM?

Search before creating, on a stable key - a company registration number where available, otherwise a normalised email or phone. When no confident match exists, record the lead and flag it for human review rather than creating automatically. Store the record id on your side so subsequent updates need no search, and make form submissions idempotent, since forms genuinely do get submitted twice.

Fireberry / Powerlink API Guide

Fireberry exposes a compact REST API - four operations over a generic record endpoint. What that design means for your code, and why the token being tied to a specific user is the detail that kills integrations months later.

Fireberry - formerly Powerlink - is an Israeli CRM with a compact REST API: four operations over a generic record endpoint, in JSON, authenticated with a token. The design is pleasant to work with, and it contains one detail that takes integrations down months after they go live.

The rename - and why search is confusing

The product rebranded from Powerlink to Fireberry, but the API host is still api.powerlink.co.il, and some documentation and support still live under the old domain.

Practically: searching "Fireberry API" and searching "Powerlink API" return different results, and both are partially relevant. Do not assume code you found is outdated merely because it says Powerlink - and do not assume it is current merely because it says Fireberry.

The shape: four operations

The API is generic over a record type:

Operation	Method and path
Create	`POST /api/record/{record}`
Update	`PUT /api/record/{record}/{id}`
Delete	`DELETE /api/record/{record}/{id}`
Query	`POST /api/query`

Two notes on this shape:

It is generic, and that is an advantage. You write one access layer taking a record type as a parameter rather than a separate function per object. The code stays small.

Reading is a POST, not a GET. That is the first point of confusion for anyone arriving from classic REST. There is no GET /api/record/account?status=active; there is a filter payload sent by POST. So you build a query object rather than a string - and plan pagination from the start, because a query returning everything works beautifully on a test account and falls over on a real one.

The detail that kills integrations: the token belongs to a user

This is the most important point in the article.

The tokenid comes from system settings - the gear icon, Integration, API Forms - where a "My Token" field appears. Every user in the system has their own unique token.

The implication is not merely technical:

Everything the integration creates is attributed to that user. If you used a particular salesperson's token, every lead from the website looks like they created it. That distorts performance reporting and produces arguments that have nothing to do with software.
That user's permissions apply to the API. If they cannot see an object in the interface, the integration will not see it either - and that manifests as missing records rather than a permission error.
If that person leaves, the integration goes down. And that happens months after launch, when nobody remembers the connection depends on one individual's account.

What to do: ask the client for a dedicated integration user - not an employee's account. Give it a clear name such as "website integration", and make sure it has exactly the permissions it needs and no more.

And document it. In a year, whoever maintains this needs to know the connection depends on that user and that it must not be deactivated.

Object and field names - what you have to discover

Because the API is generic over a record type, what you need to know is what the objects and fields are called in the specific account.

As with any CRM, an account accumulates customised fields over years of use. Two clients on the same system can require different code - exactly as with Priority and SAP Business One.

The conclusion is the same: do not price an integration without access to the account. A forum answer about a field name is correct for the account of whoever wrote it.

The matching that is all the work: identity

In most projects the CRM does not stand alone - it receives leads from a website and passes won deals to an operational system or an invoicing system.

And at every such point the same question recurs: does this record already exist?

A CRM usually has no real uniqueness constraint. The same company can appear under three spellings. The rule that holds:

Search before creating - through the query endpoint, on a stable key. A company registration number where one exists, otherwise a normalised email or phone.
If there is no confident match, do not create automatically. Record it and flag it for human review.
Store the record id on your side, so next time no search is needed at all.

CRM duplicates fail no test. They accumulate quietly and surface when someone asks why there are three open opportunities for one customer.

What must be in place

Idempotency. The same lead submitted twice from a form produces one record. Forms get submitted twice; this is not an edge case.
An error queue a human sees. A lead that failed to write is a lost lead if it is stuck in a log.
Pagination on every query. Do not rely on fetching everything.
The token as a server-side secret. It permits reading and writing all customer data - not in source control, not in logs, not in a browser.

Checklist

Request a dedicated user for the integration, not an employee's account - and document it.
Confirm its permissions cover exactly what is needed.
Get access to the account to discover object and field names - before pricing.
Build search-before-create on a stable key.
Pagination and idempotency from the start, not as an improvement.
Test what happens when the token's user is deactivated - and make sure somebody would find out.

The Fireberry (Powerlink) API: Records, Queries and the Token Trap

Key takeaways