Before you hand out your RealGreen API key: the security checklist

A RealGreen API key is not a technical detail: it is the keys to your customer list, and your customer list is the most valuable asset your company owns after its people. Names, addresses, phone numbers, emails, program history, balances: everything a competitor would pay for and everything a breach notification letter is written about. Most owners hand keys out the way this industry hands everything out, over email to whoever asked nicely, and never think about it again. What follows is the checklist we wish every owner ran, and the one we expect to be held to ourselves: what the key exposes, how to limit and rotate it, the paperwork that matters, how offboarding should work, and the red flags that should end a sales call early.

What exactly does an API key expose?

Think through what your integration partner can read once the key works: every customer record with contact details, service addresses, program and pricing history, invoice and balance data, and years of it. That is personal information about thousands of households, plus a fairly complete commercial picture of your business: your customer count, your pricing, your churn, your territories. Two sober conclusions follow. First, vendor selection is a data-custody decision, not just a features decision. Second, anyone with your key can copy the data, so the moment of handing it over is the moment that matters: there is no un-sharing later. What the API can technically do, and its call limits, are covered in the API guide; this post is about who you let use it.

How do you limit what a vendor can touch?

The principle is old and simple: every party gets the minimum access their job requires, and access is treated as a live thing you manage, not a one-time event.

• One key per vendor. Never share a single key across vendors: you lose the ability to revoke one without breaking the others, and you lose any way to attribute usage. Separate credentials per integration is the baseline.
• Ask what they actually need. A reporting vendor needs to read; it does not need to write. A quoting tool needs customers and pricing; it may not need invoice history. Vendors who request everything "to be safe" are optimizing for their convenience with your data.
• Rotate on a schedule and on events. Change keys periodically, and immediately when an employee with access leaves, when a vendor relationship ends, or when anything smells wrong. If nobody in your company knows how a key would be rotated, that is your first to-do.
• Store keys like passwords. A key pasted in an old email thread is a key you no longer control. Keys belong in a password manager, shared through it, with a record of who has them.

The paperwork: DPAs and subprocessors

A data processing agreement is the document that says, in enforceable words, what the vendor may do with your data: use it only to provide the service, protect it to a named standard, delete it when you leave, and tell you promptly if it leaks. Serious vendors have one ready and countersign without drama. Ask two follow-ups. Who are the subprocessors: the cloud hosts and third-party services your data will transit, because your data is only as safe as the least careful of them. And where does the data live: for most owners the answer just needs to be a reputable cloud provider, named plainly. None of this is legal advice; it is the minimum paper trail an owner should hold before the key changes hands, the same way you would not let a crew on a commercial property without a certificate of insurance.

How should offboarding work?

Every vendor relationship ends eventually, and the exit is where data-custody promises get tested. Decide the exit before the entrance: you revoke the key on your side (never rely on the vendor discarding it), the vendor returns your accumulated data in a usable export, then certifies deletion of their copies within a stated window, in writing. That accumulated data matters more than people expect: years of campaign history, quotes, and engagement records have real value, and whether you can take them with you is a question to settle in the contract, not the breakup call. It is also a cost question as much as a security one: switching costs are part of the true price of any integration path, which is the subject of the integration cost post.

The breach questions to ask before you sign

Nobody enjoys asking these, and the reaction is diagnostic: mature vendors answer them fluently because they have been asked before. How would you know you were breached, and how fast would you tell me? Have you had a security incident, and what changed afterward? Do you carry cyber liability insurance? Who inside your company can see my customer data, and is access logged? Do you test your security, and when was the last time someone independent looked at it? You are not auditing their infrastructure: you are checking whether security is a subject they have thought about or a word on their website.

Red flags that should end the call

• "Just email us the key and we'll get started today." Speed is nice; casual custody of your customer list is not.
• No DPA, or visible annoyance at being asked for one.
• Cannot name their subprocessors or where data is stored.
• Wants credentials broader than the product requires, or your RealGreen admin login instead of an API key.
• No answer for how you get your data out at the end.

None of these makes a vendor malicious. All of them make a vendor careless, and with this data, careless is enough. And none of this is an argument against integrating: we connect RealGreen to pretty much any platform with an API, a Zapier connection, or a native connection every week, and the well-run integrations pass this checklist without breaking stride. The same diligence posture applies to agencies generally: the agency hiring questions pair well with this checklist.

The takeaway: your API key is your customer list, and it only leaves the building once. One key per vendor, minimum scope, rotation someone owns, a signed DPA, an exit defined in advance, and a sales call that survives the breach questions. Ten minutes of diligence against years of accumulated trust in that database.

Before you hand over the key

1. Inventory today: list every party that currently holds a RealGreen key or login, and revoke the ones nobody can explain.
2. Move all keys into a password manager and delete them from old email threads.
3. Adopt one-key-per-vendor and put rotation on the calendar with a named owner.
4. Require a DPA, subprocessor list, and written exit terms from every new integration, ours included: here is how we handle the integration, and we expect the questions.
5. Run the breach questions on your next vendor call and grade the fluency of the answers, not just the features on the slide.