Double Opt-In not receiving opt-in email

Hey @jackson.aisle!

May I ask how you’re testing this? Is it possible that the double opt-in emails are being sent to spam? Also, how are you able to determine those who aren’t receiving the emails, and those who just haven’t accepted yet?

- Brian

I’m testing on a local development server. Messages aren’t going to spam - it seems like my IP has been blocked by klaviyo though because it works as expected when ran from my coworker’s machine.

@jackson.aisle - Also, it may be because you can only be subscribed to the same List exactly once.  Did you make sure to either try a different email address each time? You can use the Gmail “+” hack to create “new” email addresses on the fly for testing.  

Yes, I’ve tried different emails and even using coworker’s emails to sign up. Also, looks like I was wrong about it working from my coworker’s machine - he didn’t receive his email either, but his profile was created and he is marked as never subscribed

Hello @jackson.aisle  Could you please share the sample payload used to subscribe profile?

Are you linking the profiles to a list when subscribing them?

No list. I’m calling it like this
 

await profilesApi.subscribeProfiles({
      data: {
        type: "profile-subscription-bulk-create-job",
        attributes: {
          profiles: {
            data: [
              {
                type: "profile",
                id: profileId,
                attributes: {
                  email,
                  subscriptions: {
                    email: {
                      marketing: {
                        consent: "SUBSCRIBED",
                        consentedAt: new Date(),
                      },
                    },
                  },
                },
              },
            ],
          },
        },
      },
    })

Hey @jackson.aisle, can you share which revision of the API you’re using for this request? 

Also, would you be able to remove the consentedAt field from your request payload and let us know if that changes anything? This field is meant only for capturing historical consent so there isn’t a real use case to set it to the current datetime. 

Removing `consentedAt` doesn’t seem to have an effect.

I’m testing now and things seem to be working as expected after a fresh deploy (caller is deployed to Google Cloud Functions). I’m wondering if this could have been due to a temporary outage or IP block?

I can’t file a ticket because apparently that is not doable without a paid plan