Hi there, we've had a really strange issue that I don't know the root cause for but I think is worth documenting here in case someone else can understand it better, or if this helps anyone else in the future.
The behavior we were seeing was that the "send test email" worked fine but most civimail would come back as bounced. These emails would not show up anywhere in our sparkpost account. Civi/curl would report this as: Sparkpost error: HTTP return code 503, Sparkpost error code (Unable to contact authorization service.: ).
What we eventually found was that the API key was not included properly in the request header. This call to get the key from the setting was returning garbage (sometimes!): CRM_Sparkpost::getSetting('sparkpost_apiKey'); Replacing this with just directly adding the API key as a string in the code resolved all our issues.
I don't know what about our setup would have caused this. One possible improvement could be to check specifically for a 503 return with some debug information around this condition (other return codes are already included in this way). Or, maybe some checking on the API key in the header to check for a certain length or other validation.
Hi there, we've had a really strange issue that I don't know the root cause for but I think is worth documenting here in case someone else can understand it better, or if this helps anyone else in the future.
The behavior we were seeing was that the "send test email" worked fine but most civimail would come back as bounced. These emails would not show up anywhere in our sparkpost account. Civi/curl would report this as:
Sparkpost error: HTTP return code 503, Sparkpost error code (Unable to contact authorization service.: ).What we eventually found was that the API key was not included properly in the request header. This call to get the key from the setting was returning garbage (sometimes!):
CRM_Sparkpost::getSetting('sparkpost_apiKey');Replacing this with just directly adding the API key as a string in the code resolved all our issues.I don't know what about our setup would have caused this. One possible improvement could be to check specifically for a 503 return with some debug information around this condition (other return codes are already included in this way). Or, maybe some checking on the API key in the header to check for a certain length or other validation.
Versions: Civi 5.22.1, Drupal 7.69, sparkpost 1.3