Skip to content

Amplify Hosting returns 301 for .well-known file blocking Apple Pay verification

0

I have an application deployed on AWS Amplify Hosting using a custom domain.

I need to serve the Apple Pay domain association file at the exact path:

/.well-known/apple-developer-merchantid-domain-association

Context:

  • The file exists in my repository under: public/.well-known/apple-developer-merchantid-domain-association

  • After build, it is present in the final artifact: dist/.well-known/apple-developer-merchantid-domain-association

  • Amplify is configured with: baseDirectory: dist files: '**/*'

  • I also added a specific rewrite rule: Source: /.well-known/apple-developer-merchantid-domain-association Target: same path Type: 200 (Rewrite)

Issue: When accessing the file:

curl -I https://example.com/.well-known/apple-developer-merchantid-domain-association

The response is:

HTTP/2 301 Location: /.well-known/apple-developer-merchantid-domain-association/

Response headers show: server: AmazonS3 via: CloudFront

This suggests the request is handled at the Amplify Hosting (CloudFront/S3) layer, not by the application.

Observation: Amplify Hosting appears to treat this path as a directory and automatically appends a trailing slash, instead of serving the file directly.

Expected behavior: The file should be served with HTTP 200 at the exact path (no redirect, no trailing slash), as required for Apple Pay domain verification.

Question: Is it possible to serve a file without extension under /.well-known using Amplify Hosting without triggering trailing slash normalization?

If not, what is the recommended approach to support Apple Pay domain verification when using Amplify Hosting?

2 Answers
0

Two potential options (there are likely more):

  1. Rename the merchantid file to an .html file and add a rewrite rule:

Rename the file to include .html and use a rewrite rule to map the original path:

# In your build output:
dist/.well-known/apple-developer-merchantid-domain-association.html

Then add this rewrite rule (place it first in your rules list):

[
  {
    "source": "/.well-known/apple-developer-merchantid-domain-association",
    "target": "/.well-known/apple-developer-merchantid-domain-association.html",
    "status": "200",
    "condition": null
  }
]

Amplify's normalization will find the .html file on the first lookup (step 1 above), serve it with a 200, and your path stays clean.

  1. Reverse proxy rewrite:

Host the Apple Pay verification file externally (e.g., S3 bucket, API Gateway, or CloudFront function) and use Amplify's reverse proxy rewrite:

[
  {
    "source": "/.well-known/apple-developer-merchantid-domain-association",
    "target": "https://your-s3-bucket.s3.amazonaws.com/apple-developer-merchantid-domain-association",
    "status": "200",
    "condition": null
  }
]

Reverse proxy rewrites are evaluated before the S3 origin lookup, so the trailing-slash normalization never triggers.

AWS
answered 2 months ago
0

Problem

Amplify treats extension‑less paths as directories → adds trailing slash → returns 301 instead of 200.

Solution (rename + rewrite)

  1. Rename the file in your repo:
    public/.well-known/apple-developer-merchantid-domain-association
    public/.well-known/apple-developer-merchantid-domain-association.json

  2. Add a rewrite rule (top of list in Amplify Console):

    SourceTargetType
    /.well-known/apple-developer-merchantid-domain-association/.well-known/apple-developer-merchantid-domain-association.json200 (Rewrite)
  3. Redeploy.

Why it works

Amplify sees the .json extension → no directory‑slash redirect → serves the file directly.

No other changes needed – Apple Pay verification passes because the final served content matches the expected file.

answered a month ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.