Copper
The Copper connector reads and writes people, companies, opportunities, leads, projects and tasks through Copper's developer API.
When to use it
- You move people, companies and opportunities between Copper and another CRM.
- You push new customers from a database into Copper as people, or pull won opportunities into a warehouse.
- You read records, transform them, and write the results back with Update.
What you need
- A Copper API key.
- The email address of the Copper user the key belongs to.
Copper offers an API key only.
The email is part of the credential
Copper sends the key and the key owner's email on every request, and refuses the request when they do not match. Enter the email of the Copper user who generated the key.
A connection sees what that user sees. A key from a restricted user reads fewer records than a key from an administrator.
Set up in Copper
- In Copper, go to Settings > Integrations > API Keys and generate a key.
- Note the email of the user the key belongs to.
- In DataLug, add a Copper connection.
- Paste the API key and enter that email.
- Click Test connection.
Connect
The connection form lists its steps on the left. Open any step from that list. The Environments step holds the values that differ per environment.
Test connection is in the form footer. Beside it, Test against picks Base, the connection as saved, or an environment, whose values are applied first.
| Field | Step | What to enter |
|---|---|---|
| Auth Type | Authentication | API Key. Copper offers an API key only. |
| API Key | Authentication | From Settings > Integrations > API Keys. |
| User Email | Connection | The email of the user the API key belongs to. |
Stored secrets are never sent back to the browser. To change one, use Replace.
Supported operations
Objects. Person, Company, Opportunity, Lead, Project and Task. Copper calls contacts People.
| Action | Node | Operations |
|---|---|---|
| Query (Source) | Source node | Query, with an optional Limit |
| Load (Target) | Load node | Insert, Update, Delete |
Writes go one record per request.
Not supported: Upsert, a source filter, Copper's bulk endpoints.
How the field list is built
Copper's custom field definitions describe only the fields you added. DataLug reads one record of the object and takes the standard fields from its keys, then adds your custom fields.
A custom field's column is custom_field_ followed by its numeric id, with the
field's name as the label. A field named "Loyalty tier" might appear as
custom_field_101, labelled "Loyalty tier". Renaming the field in Copper
changes the label and keeps the column.
- A standard field's type comes from one value. Numbers, true or false and ISO dates are recognised. Anything else is text, including a field that was empty on the sampled record. The value still transfers.
- An object with no records has no standard fields. Custom fields still appear. Create one record in Copper and click Get Fields.
Limits
Copper allows 180 requests per minute, and answers 429 past it. See Copper's
request guide.
Copper returns at most the first 100,000 records of a search, so a read of a larger object stops there.
DataLug paces Copper connections at 180 requests per minute by default. Page size is at most 200.
The API limits card on the connection form is collapsed by default. Every field on it is optional, and a blank field uses the default shown below it.
| Setting | What it does | Default |
|---|---|---|
| Requests per period, Period | Paces outgoing calls. Set both to throttle. | No throttle, or the rate shown on the card. |
| Page size | Rows per request. A larger value is reduced to the provider's maximum. | The maximum shown on the card, or set by the provider. |
| Max attempts | Tries per call, including the first. | 3 |
| Cool-off (ms) | The first wait after a 429. Later waits grow from it. | 500 ms |
| Requests at once | Requests open at the same time within one run. | No limit |
A Retry-After header from the provider overrides the cool-off. The pace
applies per connection and is shared by every run on it. See
Run performance.
DataLug retries a call that the provider refused with 429, and a call that
could not connect. A read is also retried after a 408, a 5xx or a dropped
connection. A write is retried only after a 429 or a failed connection.
A Retry-After delay of up to one minute is honoured. A longer one fails the
call with the 429.
Troubleshooting
| What you see | What it means | What to try |
|---|---|---|
401 on test with a new key | User Email does not match the key's owner. | Enter the email of the user who generated the key. |
401 after nothing changed | The key was revoked, or its user was deactivated. | Generate a key under Settings > Integrations > API Keys and paste it with Replace. |
| An object reads fewer records than you see in Copper | The key belongs to a restricted user. | Use a key from a user who can see the records the data pipeline needs. |
| A field is missing from the picker | The object has no records to read standard fields from. | Create one record in Copper and click Get Fields. |
A column called custom_field_101 | A custom field, named by its id. | Read the label beside it. |
| A number field is offered as text | It was empty on the sampled record. | Map it. The value still transfers. |
429 Too Many Requests | Past 180 requests a minute. | The run backs off and retries. If it recurs, lower Requests per period. |
Related
- Source node and Load node.
- Connections for environments and sharing.
- HubSpot and Insightly.