Updating a Subscriber Via the API

Use this API to update a subscriber's details when they change in your site, for instance if a customer switches to a new email address. All fields are optional - any field that is not provided will not be updated.

Do an HTTP PUT like so:

[ ~ ] $ curl -i -u 28068fe710ed67dd38de8bcd48b0544cbabcfb03:X \
-X PUT -H 'Content-Type: application/xml' \
-d '
<subscriber>
  <email>joe2@example.com</email>
  <screen-name>joe the man</screen-name>
</subscriber>' \
https://spreedly.com/api/v4/meresheep/subscribers/44.xml

If successful, a 200 (OK) status code is returned.

A 404 (Not Found) status code is returned if the subscriber is not found.

Return to the Integration Reference ↑

Extra Credit

You can change the customer-id of the subscriber using the new-customer-id attribute in the API call.

[ ~ ] $ curl -i -u 28068fe710ed67dd38de8bcd48b0544cbabcfb03:X \
-X PUT -H 'Content-Type: application/xml' \
-d '
<subscriber>
  <new-customer-id>589</new-customer-id>
</subscriber>' \
https://spreedly.com/api/v4/meresheep/subscribers/44.xml

If successful, a 200 (OK) status code is returned.

A 404 (Not Found) status code is returned if the subscriber is not found.

A 403 (Forbidden) status code is returned if the new-customer-id is already in use.

Why new-customer-id rather than customer-id?

We made it a different field because changing the customer-id is semi-destructive (from your application's perspective) and because we didn't want anyone getting confused given that the customer-id is in the URL and in the body. We know it's a bit annoying, but we consider this to be a potentially "dangerous" operation and thus want it to be non-trivial in use.

More Extra Credit

If you're using the Payments API, you can also update payment information with this call:

[ ~ ] $ curl -i -u 28068fe710ed67dd38de8bcd48b0544cbabcfb03:X \
-H 'Content-Type: application/xml' \
-d '
<subscriber>
  <email>joe2@example.com</email>
  <payment-method>
    <credit-card>
      <number>4111111111111111</number>
      <verification-value>234</verification-value>
      <month>1</month>
      <year>2100</year>
      <first-name>Joe</first-name>
      <last-name>Bob</last-name>
    </credit-card>
  </payment-method>
</subscriber>' \
https://spreedly.com/api/v4/meresheep/subscribers/44.xml

The success result is the same, but there are some additional errors to handle, due to the payment method being verified:

A 404 (Not Found) is returned if the subscriber doesn't exist.

A 422 (Unprocessable Entity) is returned if any required information is missing or the payment information otherwise fails verification. Spreedly will additionally return an XML array of error information.

A 403 (Forbidden) is returned if the new payment information fails to authorize or you do not have a gateway configured.

A 403 (Forbidden) is returned if the subscriber is not currently active or if the subscriber doesn't have a recurring subscription.

A 504 (Gateway Timeout) is returned if the payment gateway fails to respond in a timely manner.

Olark Livehelp