DEV Community: Rob Askam

Six decisions behind a webhook for personal data

Rob Askam — Fri, 13 Nov 2026 08:18:32 +0000

Most webhook advice is about reliability: retries, signatures, idempotency. All of it applies. But when the thing that changed is someone's home address or email, there is a second set of questions, about what happens when the webhook, the log it lands in or the account behind it falls into the wrong hands.

I run ContaShare, where a person keeps their contact details in one account and chooses which companies can read them. When they change a detail, each company they share it with gets a webhook. Here are six decisions from building that, and what each one cost.

1. The webhook carries no personal data

This is the whole payload:

{
    "id": "e5aeb9bf-5676-41bc-9261-fc88920aaa56",
    "type": "address",
    "action": "update",
    "resource_url": "https://contashare.com/api/v1/address/e5aeb9bf-5676-41bc-9261-fc88920aaa56"
}

No address, no name, no customer ID. The receiver fetches resource_url with that customer's OAuth token to get the new version.

Putting the new address in the payload would save the receiver a request. But webhook bodies end up in places nobody audits: request logs, error trackers, a tunnelling tool's history, the retry queue of whatever sits in front of the app. A payload with nothing in it can be logged anywhere.

It also means permission is checked at the moment of reading, not the moment of sending. If the customer stops sharing between the webhook and the fetch, the fetch returns 404 and the company never sees the new address.

The cost: the receiver has to store which customer each record id belongs to, and make a second request.

2. Every webhook means "fetch the latest"

A payload with values in it has an ordering problem. Two changes a minute apart, delivered out of order after a retry, leave the receiver holding the older one.

A payload that only says "this record changed" doesn't. Two webhooks for the same record are identical, handling one twice is harmless, and whichever arrives last still fetches the current version. Receivers can fold queued duplicates into one fetch, and I tell them to.

The cost: you can't offer a history of changes through the webhook. For contact details nobody has asked for one.

3. Each company gets its own ID for the same person

GET /api/v1/me returns the ID a company knows a customer by. It never changes for that company, and every other company gets a different one for the same person.

A single global user ID is easier to build and to debug. It is also a join key: any two companies holding it could match their customer lists against each other without asking anyone. Giving each company its own ID removes that option entirely.

The cost: support is harder. When a company quotes an ID at me, it only means something alongside which company is asking.

4. A change can wait an hour, on purpose

This is the one that surprised me most while building it.

A service that updates someone's email at every company at once is a very good target. Many sites reset a password by emailing the address on file. So if someone gets into a ContaShare account and changes the email, every connected company would be told the attacker's address, and the attacker then asks each one for a password reset.

So a change to anything a company already holds waits an hour before it goes anywhere. The owner is emailed at once, at the old address too, with a link that cancels the change and locks the thief out. Until the hour is up there is no webhook and the API keeps returning the version the company already has.

A change confirmed with an established passkey or two-factor, or with a link emailed to the owner, skips the wait. "Established" matters: a second factor added in the last 72 hours doesn't count, or the thief would add their own and carry on.

The cost: a real customer with no second factor waits an hour for their new address to arrive. I kept it short for that reason. It only needs to be long enough for the owner to see the warning.

5. The receiver is told not to trust the change either

The hold reduces the risk and doesn't remove it. So the docs say it plainly: treat an update as new contact details, not as proof of who someone is. Before a changed email or phone number is used to reset a password or send a login code, tell the old address and ask the customer to confirm in your own app.

There is a webhook for the worst case too. If an account is reported stolen, it is locked, and each company gets locked for the records it holds. Fetches return 423 until unlocked arrives. The advice on locked is to treat anything received for that customer in the last 7 days as possibly not from them.

The cost: the integration guide is longer and less cheerful than a marketing page would like. I think that's the right way round.

6. Stopping sharing sends nothing

When a customer stops sharing a record with a company, that company gets no webhook. Its next fetch of the record returns 404, the same as for a record that was deleted, and its token keeps working for anything else the customer still shares.

A "revoked" webhook would be tidier for the receiver. But it would announce a decision the customer may not want announced, and it can't be something a company's endpoint is able to delay or fail. Stopping sharing takes effect straight away, with nothing on the other side to wait for.

The cost: receivers must handle 404 as "remove this", which the guide repeats in three places.

The ordinary parts still matter

For completeness, the reliability basics are all there:

Every request has a Signature header: the HMAC-SHA256 of the raw body with the team's secret. Check it against the raw body, with a constant-time comparison.
A failed delivery is tried 3 times, 10 and then 100 seconds apart. After that it sits in a delivery history where the company can send it again once their endpoint is fixed.
Webhooks are free and so are failed API calls. A company pays for a successful read: 1.25p for an address.

What I'd tell someone building the same thing

Ask what your webhook is worth to someone who shouldn't have it, and what your API does for someone who took over an account. For most data the answer is "not much", and a full payload is fine. For anything another site would use to decide who someone is, the answers shape the design more than the retry policy does.

If you want to see how it reads from the receiving side, the webhooks guide and API reference are public, and there are packages for Laravel, Node and Python. New company accounts get 1,000 free credits with no card: contashare.com/businesses.

I'd welcome holes being picked in any of this, especially number 4.

Keep customer addresses current in Laravel with webhooks

Rob Askam — Fri, 13 Nov 2026 08:17:25 +0000

Every app that stores a customer's address has the same problem: the address was right on the day it was typed. People move, and your app is a long way down the list of who they tell.

I built ContaShare to turn that round. A customer keeps their address, email, phone number and name in one account and ticks which of them your app may read. When they change one, your app gets a webhook and fetches the new version.

This post adds it to a Laravel app: an OAuth sign-in button with Socialite, then a webhook that keeps the address current. It takes about half an hour.

What you need

A Laravel app with a users table.
A ContaShare company account. It comes with 1,000 free credits and needs no card.
An OAuth client, created under API Clients in that account, with your callback URL as its redirect URI.

Install the driver

composer require contashare/socialite

Add the client to config/services.php:

'contashare' => [
    'client_id' => env('CONTASHARE_CLIENT_ID'),
    'client_secret' => env('CONTASHARE_CLIENT_SECRET'),
    'redirect' => env('CONTASHARE_REDIRECT_URI'),
    'webhook_secret' => env('CONTASHARE_WEBHOOK_SECRET'),
],

And give your users somewhere to keep the connection:

Schema::table('users', function (Blueprint $table) {
    $table->string('contashare_id')->nullable()->unique();
    $table->text('contashare_token')->nullable();
    $table->text('contashare_refresh_token')->nullable();
});

Cast both tokens as encrypted on the model. They read a person's home address, so treat them like passwords.

Sign up and sign in

Two routes. The first sends the customer to ContaShare, where they see their records and tick the ones your app may read. The second handles them coming back.

use App\Models\User;
use Illuminate\Support\Facades\Auth;
use Illuminate\Support\Str;
use Laravel\Socialite\Facades\Socialite;

Route::get('/auth/contashare', fn () => Socialite::driver('contashare')->redirect());

Route::get('/auth/contashare/callback', function () {
    $contashare = Socialite::driver('contashare');
    $customer = $contashare->user();

    $user = User::firstWhere('contashare_id', $customer->getId());

    if ($user === null) {
        // New customer: one call returns everything they shared.
        $shared = $contashare->sharedData($customer->token) ?? [];
        $email = collect($shared['emails'] ?? [])->sortByDesc('email_detail.is_verified')->first();
        $name = $shared['names'][0]['name_detail'] ?? null;

        abort_if($email === null, 422, 'Share an email address to sign up.');

        // Never sign someone in to an account that already has this email address.
        abort_if(User::where('email', $email['email_detail']['email_address'])->exists(), 409, 'Log in with your password instead.');

        $user = User::create([
            'contashare_id' => $customer->getId(),
            'name' => trim(($name['first_name'] ?? '').' '.($name['last_name'] ?? '')) ?: Str::before($email['email_detail']['email_address'], '@'),
            'email' => $email['email_detail']['email_address'],
            'password' => Str::random(40),
        ]);

        // Remember which records are this customer's. The webhook needs it.
        foreach ($shared['addresses'] ?? [] as $address) {
            $user->addresses()->create([
                'contashare_record_id' => $address['id'],
                'line_one' => trim($address['address_detail']['building_number'].' '.$address['address_detail']['address_line_one']),
                'city' => $address['address_detail']['city'],
                'postcode' => $address['address_detail']['postcode'],
            ]);
        }
    }

    $user->forceFill([
        'contashare_token' => $customer->token,
        'contashare_refresh_token' => $customer->refreshToken,
    ])->save();

    Auth::login($user);
    request()->session()->regenerate();

    return redirect('/dashboard');
});

Three things in there are worth a second look.

getId() is your own ID for this person. It comes from GET /api/v1/me, which is free. It never changes, and another company gets a different ID for the same person, so two companies can't compare notes.

The 409 matters. If someone already registered with that email, don't sign them in or link the accounts, even when the email is verified. Otherwise every account in your app, an admin's included, is only as safe as whichever ContaShare account holds that address. Ask them to log in the usual way and connect from their settings.

Store the record ids. The webhook in the next section tells you which record changed, not whose it is.

Hear about changes

Create a webhook under Webhooks in your ContaShare team settings, and put the secret it shows you in CONTASHARE_WEBHOOK_SECRET. It is shown once.

The webhook is small on purpose. It carries no personal data, only what changed and where to fetch it:

{
    "id": "e5aeb9bf-5676-41bc-9261-fc88920aaa56",
    "type": "address",
    "action": "update",
    "resource_url": "https://contashare.com/api/v1/address/e5aeb9bf-5676-41bc-9261-fc88920aaa56"
}

Check the signature against the raw body, queue the work and answer straight away:

use App\Jobs\SyncContaShareRecord;
use ContaShare\Socialite\WebhookSignature;
use Illuminate\Http\Request;

Route::post('/webhooks/contashare', function (Request $request) {
    abort_unless(WebhookSignature::isValid(
        $request->getContent(),
        $request->header('Signature'),
        config('services.contashare.webhook_secret'),
    ), 401);

    SyncContaShareRecord::dispatch($request->input('type'), $request->input('id'), $request->input('action'), $request->input('resource_url'));

    return response()->noContent();
});

Exempt that URL from CSRF checks in bootstrap/app.php. The signature does that job.

The job fetches the record with the customer's own token:

class SyncContaShareRecord implements ShouldQueue, ShouldBeUniqueUntilProcessing
{
    use Queueable;

    public function __construct(public string $type, public string $id, public string $action, public string $resourceUrl) {}

    public function uniqueId(): string
    {
        return $this->type.':'.$this->id;
    }

    public function handle(): void
    {
        if ($this->type !== 'address') {
            return;
        }

        $address = Address::firstWhere('contashare_record_id', $this->id);

        if ($address === null) {
            return;
        }

        if ($this->action === 'delete') {
            $address->delete();

            return;
        }

        if ($this->action !== 'update') {
            return;
        }

        $response = Http::withToken($address->user->contashare_token)->acceptJson()->get($this->resourceUrl);

        if ($response->notFound()) {
            // Deleted, or the customer stopped sharing it.
            $address->delete();

            return;
        }

        $detail = $response->throw()->json('address_detail');

        $address->update([
            'line_one' => trim($detail['building_number'].' '.$detail['address_line_one']),
            'city' => $detail['city'],
            'postcode' => $detail['postcode'],
        ]);
    }
}

ShouldBeUniqueUntilProcessing folds two webhooks for the same record into one fetch while the first is still queued. Every webhook means "fetch the latest", so handling one twice is harmless.

Press Send test on the Webhooks page to try your endpoint. The test uses a random id, so your job finds no address and stops, which is what you want.

Things to know before you ship

A 404 on fetch is a delete. The customer removed the record or stopped sharing it with you. They can do that at any time, and stopping sharing sends no webhook of its own.
Tokens last a year. Refresh well before then with Socialite::driver('contashare')->refreshToken($refreshToken) and store the new pair.
A changed email is new contact details, not proof of identity. Don't let it reset a password in your app without telling the old address first.
A change can take up to an hour to arrive. A change to something you already hold waits an hour unless the customer confirmed it with a passkey, two-factor or an emailed link. That gives the owner time to stop a change made from a stolen account.
It covers customers who connect. It won't clean a list of people who haven't, and it isn't a postcode lookup. Keep the postcode lookup on your form and use this for the years afterwards.

What it costs

You pay per successful API call with credits. The first call that returns everything a new customer shared is 1 credit (0.625p). Fetching an address is 2 credits (1.25p). GET /api/v1/me, webhooks and failed calls are free, and there is no monthly fee.

So an address costs you 1.25p when it changes, and nothing in the years it doesn't.

Address lookup API pricing: what you are paying for

Rob Askam — Thu, 12 Nov 2026 09:00:00 +0000

"Address lookup" covers several different jobs, and they are priced differently because they cost different amounts to provide. Before comparing prices it helps to know which job you need doing. This guide explains the main kinds, how each is usually charged and how to work out what you will really spend.

Three jobs that get called address lookup

Postcode lookup and address autocomplete. A customer types a postcode or the start of an address into your form and picks theirs from a list. It makes forms quicker and stops typing mistakes. This is what most people mean by an address lookup API.

Address validation and cleansing. You already hold addresses and want to check they exist and are formatted correctly, often in bulk before a mailing.

Current customer address. You want to know where a particular customer lives now, not whether an address exists. A postcode lookup cannot answer this. It tells you that 18 Harbour Street is a real address, and nothing about whether your customer still lives there.

Most businesses need the first job at sign-up and the third for as long as the customer stays with them.

How postcode lookup is priced

In the UK, postcode lookup services are mostly built on Royal Mail's Postcode Address File, which is licensed. Part of what you pay covers that licence, so the price has a floor however efficient the provider is.

The usual models are:

Pay per lookup , with credits bought in packs. The price per lookup falls as the pack gets bigger.
A monthly or yearly plan with an allowance of lookups, and a charge for going over it.
A licence per user or per site for internal systems such as a call centre.

Check what counts as one lookup. Some services charge when the customer picks an address, some charge for each search as they type, and some charge again if the same customer comes back.

What to compare besides the price per lookup

Minimum spend and expiry. A cheap lookup in a pack that expires after a year costs more than it looks if you do not use it all.
Monthly fees that apply whether or not you use the service.
What a failed or empty search costs.
Coverage. Do you need addresses outside the UK, or properties that are newly built?
What happens afterwards. The address was right on the day it was typed. How will you find out when it stops being right?

That last question is usually missing from a price comparison, and it is where a lot of money goes: returned post, failed deliveries and staff time spent tracing customers who moved.

The cost of checking again

An address captured perfectly still goes out of date when the customer moves. The traditional answers are to screen your list against mover and suppression files, which is charged per record matched, or to ask customers to confirm their details, which most of them ignore. Our guide to keeping customer addresses up to date compares these.

Either way you pay to check records that have not changed in order to find the few that have.

Paying only when something changes

ContaShare works the other way round. Your customer keeps their own address, phone number, email and name up to date in a free ContaShare account and chooses to share them with you. You read the current version through an API, and a webhook tells you when they change something, so you fetch an address only when there is a new one.

Reading an address costs 1.25p at list price, and less in larger credit packs. Webhooks and failed requests are free. There is no monthly fee and no minimum spend. It costs that little because there is no address file to license: the customer is the source.

It is not a postcode lookup and does not replace one. It covers customers who have connected their ContaShare account to you, so it will not clean a list of people who have not. Coverage grows as you add the sign-in button to your site and send customers your invite link.

Working out your own numbers

Count the lookups you make at sign-up. That is your postcode lookup bill, and it depends on new customers, not on how many you have.
Estimate how many customers move in a year, and what a wrong address costs you each time in post, redelivery and staff time.
Compare that with the cost of hearing about each move when it happens.

For many businesses the cheapest set-up is both: a postcode lookup on the form, and a live connection for the years afterwards.

Try it

Read how businesses use ContaShare, with current prices, or go straight to the integration guide. New business accounts get free credits to test with, and no card is needed.

How to keep customer addresses up to date

Rob Askam — Thu, 12 Nov 2026 09:00:00 +0000

Every customer database starts going out of date the day it is filled in. People move, change phone numbers and abandon email addresses, and most of them do not tell you. This guide looks at why that happens, what it costs and the ways to fix it.

Why addresses go stale

A customer who moves has dozens of organisations to tell. They start with the ones that matter most to them, such as their bank and the DVLA, and run out of energy long before they reach a retailer, a membership body or a utility they are leaving. Nobody decides not to tell you. You are simply far down a long list.

The same goes for phone numbers and email addresses, with one difference: nothing bounces when a mobile number changes hands. Your texts just go to someone else.

What it costs

Returned and lost post. Printing, postage and handling for letters that come back marked "gone away", and for those that never come back at all.
Failed deliveries , redelivery fees and replacement goods.
Missed payments and renewals , because the reminder went to the old address.
Customer service time spent tracing people.
Fraud and privacy risk. A statement posted to a former address puts personal data in a stranger's hands. That can be a reportable data breach.
Compliance. UK data protection law requires personal data to be accurate and, where necessary, kept up to date. See what the accuracy principle asks of you.

Five ways to keep details current

1. Ask customers to check their details

Prompt at login, in the app and in regular emails: "Is this still your address?" It is cheap and should be standard. Its limit is that it depends on the customer acting, and it cannot reach someone whose email address has also changed.

2. Validate at the point of capture

Postcode lookup and email and phone validation make sure details are well formed when they are typed in. This prevents typing errors. It does nothing once a correct address becomes an old one.

3. Act on bounces and returns

Treat every returned letter, hard bounce and failed delivery as a signal: flag the record, stop posting to it and ask the customer through another channel. This is essential hygiene, but it only tells you an address is wrong, not what the right one is, and only after you have paid to send something.

4. Screen against mover and suppression files

Data suppliers sell files of people who have moved or died, built from sources such as redirection records. Screening a mailing list against them removes known gone-aways, and some services supply a new address. It works on your existing data without the customer doing anything. It is a periodic batch process, coverage is partial, and you need to be confident of your lawful basis for using a new address you were not given by the customer.

5. Let customers share live details with you

Rather than holding a copy that ages, connect to a record the customer keeps current themselves. This is what ContaShare does:

A customer keeps their address, phone number, email and name in a ContaShare account.
They sign in to your service with ContaShare and tick which details you may read.
You fetch those details through an API, and receive a signed webhook when one changes, so you only fetch again when there is something new.
The customer can stop sharing at any time.

Its limit is the reverse of screening: it covers only customers who have connected their account, so it does not clean an existing mailing list. It grows as you invite customers, for example with a link in your emails or at checkout. For those customers the details are current, supplied by the person themselves, with their permission recorded.

Which should you use?

Use more than one. Validate at capture, act on bounces, and prompt customers to review. Then choose between periodic screening, a live connection or both, depending on how much a wrong address costs you. Where a wrong address means a failed delivery, a missed renewal or a letter with personal data going astray, hearing about a move when it happens is worth more than finding out at the next mailing.

Try it

ContaShare has no monthly fee: you buy credits and pay per API request, and reading a customer's current address costs 1.25p. Read how businesses use ContaShare, or see the integration guide for the technical detail.

UK GDPR accuracy principle: keeping contact data up to date

Rob Askam — Thu, 12 Nov 2026 09:00:00 +0000

The UK GDPR sets out seven principles for handling personal data. The fourth is accuracy: personal data must be accurate and, where necessary, kept up to date, and inaccurate data must be erased or corrected without delay. For most organisations the data this bites on first is the plainest: names, addresses, phone numbers and email addresses.

This is a practical overview, not legal advice. The Information Commissioner's Office (ICO) publishes the authoritative guidance.

What the principle says

In summary, you should:

take reasonable steps to make sure the personal data you hold is not incorrect or misleading
keep it up to date where that is necessary for what you use it for
correct or erase it promptly when you find it is wrong
consider any challenge to its accuracy

"Where necessary" depends on what the data is for

You do not have to update everything for ever. The question is whether out-of-date data would matter for your purpose.

A record of where an order was delivered in 2023 is accurate as a historical record. It does not need changing when the customer moves.
The address you send statements to is used today. If it is out of date, personal and financial information goes to the wrong household.

Contact details used for ongoing communication nearly always fall in the second group.

What counts as "reasonable steps"?

It scales with the risk. The more harm an error could cause, the more you are expected to do. Reasonable steps for contact data commonly include:

Recording where the data came from and when it was last confirmed.
Making it easy for people to update their own details , online and without a phone call.
Prompting people to review their details periodically, and before anything sensitive is posted.
Acting on evidence that data is wrong: returned post, bounced email, a failed delivery or a text answered by a stranger.
Not repeating the error: when one system is corrected, the others that hold a copy are corrected too.

Doing nothing until a customer complains is hard to defend where you are sending anything confidential.

The right to rectification

Individuals have the right to have inaccurate personal data corrected. When someone asks:

you must respond within one month , which can be extended for complex requests
you cannot normally charge a fee
if you have shared the data with others, you should tell them about the correction where possible
the request can be made verbally or in writing, to any part of your organisation

A change of address is the commonest rectification request there is, even though nobody calls it that. Your process for it should be quick and should reach every system.

When wrong contact data becomes a breach

Sending personal data to an old address or a recycled phone number can be a personal data breach: an unauthorised disclosure. Depending on the risk to the person, you may need to report it to the ICO within 72 hours and tell the individual. A bank statement, a medical appointment letter or a payslip reaching the wrong household is exactly the kind of incident that gets reported.

Keeping contact details accurate is therefore also part of keeping data secure.

Ways to reduce the risk

Our guide to keeping customer addresses up to date compares the options, from review prompts to mover files. In short:

Validate details when they are captured.
Give customers a simple way to change them.
Treat bounces and returns as signals and act on them.
Keep one source of truth, so a correction reaches every system.
Where you can, get changes from the individual as they happen.

Where ContaShare fits

ContaShare supports the fifth point. Your customers keep their own address, phone number, email and name current in a ContaShare account, and choose which of them your organisation may read. You read the current version through an API and receive a notification when something changes.

For accuracy, that means the data comes from the individual, with a record of their permission, and corrections arrive without your asking. It covers the customers who connect their account, not your whole database, so it sits alongside the other steps and does not replace them. You remain the controller of the data you hold and responsible for your own compliance.

See how businesses use ContaShare.

DEV Community: Rob Askam

Six decisions behind a webhook for personal data

1. The webhook carries no personal data

2. Every webhook means "fetch the latest"

3. Each company gets its own ID for the same person

4. A change can wait an hour, on purpose

5. The receiver is told not to trust the change either

6. Stopping sharing sends nothing

The ordinary parts still matter

What I'd tell someone building the same thing

Keep customer addresses current in Laravel with webhooks

What you need

Install the driver

Sign up and sign in

Hear about changes

Things to know before you ship

What it costs

Links

Address lookup API pricing: what you are paying for

Three jobs that get called address lookup

How postcode lookup is priced

What to compare besides the price per lookup

The cost of checking again

Paying only when something changes

Working out your own numbers

Try it

How to keep customer addresses up to date

Why addresses go stale

What it costs

Five ways to keep details current

1. Ask customers to check their details

2. Validate at the point of capture

3. Act on bounces and returns

4. Screen against mover and suppression files

5. Let customers share live details with you

Which should you use?

Try it

UK GDPR accuracy principle: keeping contact data up to date

What the principle says

"Where necessary" depends on what the data is for

What counts as "reasonable steps"?

The right to rectification

When wrong contact data becomes a breach

Ways to reduce the risk

Where ContaShare fits