Have To for External Requirements

By the end of this lesson, you will be able to...

• Use have to when a technical action is required because of an external deadline, policy, platform rule, customer need, or operational constraint.

• Separate have to from must: both can be strong, but they usually point to different sources of obligation.

• Write a short status update that names the required action, the external reason, and the deadline.

Idea in one sentence: Use have to when the work is required because something outside the sentence is forcing the team to act.

Core Insight

Lesson 007 used must for a strong technical requirement:

Every request must include an idempotency key.

That sentence sounds like a rule in the design. It belongs in an API contract, a review comment, or a checklist. If the request does not include the key, the request violates the rule.

Now compare this sentence:

We have to rotate the key before Friday.

This is also strong. It is not a suggestion. The team cannot simply ignore it.

But the source of the obligation feels different.

Have to often points to pressure from outside the design itself: a deadline, a certificate expiry, a security policy, a vendor requirement, a customer launch, a compliance check, or an incident response plan.

The useful question is:

What is forcing this action?

If the answer is a rule inside the system, must may be better:

Every request must include an idempotency key.

If the answer is an external condition, have to often sounds more natural:

We have to rotate the key before Friday because the current key expires.

Both sentences are serious. They just point in different directions.

The Small Situation

Imagine a service that signs webhook payloads for customers.

The service uses a signing key. Customers use the public key to verify that the webhook really came from your platform. The current key is going to expire on Friday at 18:00 UTC.

The team has a few jobs to do:

• create the new key;
• publish the new public key;
• make the service sign with the new key;
• keep the old key long enough for customers to finish the transition;
• remove the old key after the deadline.

A teammate writes this in chat:

We must rotate the key before Friday.

That sentence is understandable. It is not wrong in a dramatic way. But it sounds as if the speaker is stating a formal rule. In many day-to-day engineering updates, the more natural sentence is:

We have to rotate the key before Friday.

Why?

Because the deadline is doing the work. The team is not inventing a design rule in this sentence. The team is responding to an external fact: the current key expires.

The stronger version names the reason:

We have to rotate the key before Friday because the current key expires at 18:00 UTC.

Now the reader can see the action, the deadline, and the pressure.

The Shape of a Good Have To Sentence

A useful have to sentence usually has three visible parts:

who + have to + action + external condition

For example:

We have to rotate the key before Friday.

The parts are:

That sentence is clear, but it may still be too thin for technical work. A good status update often adds the source of pressure:

We have to rotate the key before Friday because the current key expires at 18:00 UTC.

Now the sentence answers the question a reviewer will ask:

Why before Friday?

This is the main discipline for have to: do not only say that something is required. Show what makes it required.

Must vs Have To

Must and have to overlap. Native speakers use both for strong obligation. You will see both in real documentation, chat, and code review.

For this track, use this practical distinction:

Look at the difference:

Every request must include an idempotency key.
We have to rotate the key before Friday.

The first sentence sounds like a design rule. You could put it in an API specification.

The second sentence sounds like required work. You could put it in a sprint update, incident plan, release checklist, or security reminder.

The source is different:

Design rule:
Every retryable request must include an idempotency key.

External pressure:
We have to rotate the signing key before Friday because the current key expires.

This distinction is not a legal rule. It is a reader-expectation rule. It helps the reader understand whether you are defining a property of the system or reporting an obligation created by the current situation.

A Worked Status Update

Start with a vague update:

Key rotation.

This is too compressed. It may be a task title, but it is not a useful update. It does not say whether the work is optional, urgent, blocked, done, or risky.

Step 1: add have to and the action.

We have to rotate the key.

Now the reader knows the action is required.

Step 2: add the deadline.

We have to rotate the key before Friday.

Now the reader knows when the requirement matters.

Step 3: add the external reason.

We have to rotate the key before Friday because the current key expires at 18:00 UTC.

Now the reader knows why the work is required.

Step 4: add the current status.

We have to rotate the key before Friday because the current key expires at 18:00 UTC. The new key is generated, but two services still read the old key from the secret store.

Now the update is useful. It says what the team has to do, why, when, and what remains.

You can make it even more operational:

We have to rotate the signing key before Friday because the current key expires at 18:00 UTC. The API can publish the new public key today, but the worker cannot switch until the secret store change is deployed.

This sentence reuses earlier lessons:

• can for available capability: The API can publish the new public key today.
• cannot for a hard current limit: The worker cannot switch until the secret store change is deployed.
• have to for external requirement: We have to rotate the signing key before Friday.

The grammar is small, but the technical meaning is precise.

Where Have To Sounds Natural

Have to is common in technical status because teams often react to constraints.

Use it for deadlines:

We have to finish the migration before the old database is decommissioned.

Use it for platform or vendor rules:

The client has to send the new header after the gateway upgrade.

Use it for security policy:

We have to remove the shared admin token before the audit.

Use it for operational recovery:

We have to drain the queue before we can restart the worker.

Use it for customer commitments:

We have to enable the fallback path before the launch window.

In each case, the sentence points to pressure around the team. The team may own the work, but the reason comes from a deadline, dependency, policy, incident, or promise.

From Literal Translation to Technical English

Spanish often lets the speaker use one direct shape for many obligations:

Tenemos que rotar la clave antes del viernes.

The close English sentence is good:

We have to rotate the key before Friday.

The problem is not the grammar. The problem is usually the missing technical context. In Spanish, the team may already share the context in the conversation. In written technical English, especially in tickets and reviews, the reader may arrive later and need the reason on the page.

So the better technical version is:

We have to rotate the key before Friday because the current key expires at 18:00 UTC.

Notice what changed. You did not make the sentence fancy. You made the reason inspectable.

Here are three useful rewrites:

The lesson is not "always make the sentence longer." The lesson is "add the detail that explains the obligation."

If the reason is already obvious in the previous sentence, short is fine:

The current key expires on Friday. We have to rotate it before the expiry window.

If the reason is not visible, include it:

We have to rotate the key before Friday because the current key expires at 18:00 UTC.

The Negative Form: Do Not Have To

Be careful with the negative form.

Do not have to means something is not required.

It does not mean something is forbidden.

Compare:

The client does not have to send the legacy header.
The client must not send the legacy header.

These are very different.

Does not have to means optional:

The client can send the new header, but it does not have to send the legacy header.

Must not means prohibited:

The client must not send the legacy header after the cutoff date.

This track will return to that contrast in lesson 013. For now, remember the simple rule:

do not have to = not required
must not = forbidden

This matters in technical writing because a small grammar mistake can change system behavior. Optional and forbidden are not close meanings.

Have To vs Need To

Need to is also common:

We need to rotate the key before Friday.

In many technical conversations, need to and have to are close. Both can describe required work.

But they have a slightly different feel.

Have to often highlights external pressure:

We have to rotate the key before Friday because the current key expires.

Need to often highlights practical necessity:

We need to rotate the key before we can enable the new signing path.

This is not a hard border. Engineers mix them all the time. The useful habit is to choose the one that makes the reason clearer.

If the sentence is about a deadline, policy, or outside requirement, have to is a good first choice.

If the sentence is about a dependency inside the work plan, need to may be a good first choice. Lesson 012 will spend more time on need to and need not.

Common Mistakes

The first mistake is hiding the source of pressure:

Weak:
We have to rotate the key.

Better:
We have to rotate the key before Friday because the current key expires.

The weak sentence may be fine in a chat where everyone already knows the context. In a ticket, review, or incident document, the better sentence saves time.

The second mistake is using have to for a system rule that should be written with must:

Less precise:
Every retryable request has to include an idempotency key.

More contract-like:
Every retryable request must include an idempotency key.

The first sentence is understandable. The second sentence sounds more like a rule that belongs in an API contract.

The third mistake is combining have to with uncertainty in a confusing way:

Confusing:
We might have to rotate the key before Friday maybe.

Better: We might have to rotate the key before Friday if the vendor disables the old algorithm.

`Might have to` is useful when the requirement is possible but not confirmed. If you use it, name the condition.

The fourth mistake is making `have to` sound helpless:

```text
Weak:
We have to do many changes because security.

Better:
We have to rotate the key, remove the shared token, and update the webhook docs before the audit.

Have to should not replace ownership. It can explain pressure, but the sentence should still name the action clearly.

A Small Planning Trace

Here is a simple plan written with have to:

This plan is not fancy. That is the point. It makes the external deadline visible in small pieces.

You can combine it with the previous lesson:

The webhook API must accept signatures from both keys during the transition window. We have to keep the old key available until Friday because some customers cache the public key.

The first sentence states a system requirement.

The second sentence explains operational pressure.

Together, they are clearer than one long sentence trying to do both jobs.

The Trade-Off

The trade-off with have to is that it makes obligation sound natural and urgent, but it can hide the reason if you stop too early.

This sentence is easy:

We have to rotate the key.

But it leaves the reader asking:

• Who decided this?
• What deadline matters?
• What breaks if we do not do it?
• Is this a design rule, a security policy, or a customer promise?

So use have to, then add the external source when the reader needs it:

We have to rotate the key before Friday because the current key expires at 18:00 UTC.

That sentence gives the obligation without making the reader guess.

Quick Check

Choose the better sentence for each situation.

Situation 1: You are writing an API contract.

A. Every request must include an idempotency key.
B. Every request has to include an idempotency key because we feel it is important.

Better: A. It sounds like a clean rule.

Situation 2: You are writing a security update about a key that expires soon.

A. We have to rotate the key before Friday because the current key expires.
B. We might rotate the key before Friday, but no reason is visible.

Better: A. It names the required action and the external deadline.

Situation 3: You are writing about a possible future requirement.

A. We might have to rotate the key before Friday if the vendor disables the old algorithm.
B. We have to maybe rotate the key before Friday if something happens.

Better: A. It keeps the uncertainty in might and names the condition.

Daily Practice Lines

Repeat these three lines during the day:

We have to rotate the key before Friday.
Every request must include an idempotency key.
The spike might be related to the deploy.

Then change one noun or condition:

key -> certificate -> token -> secret -> webhook key
Friday -> the audit -> the launch window -> the gateway upgrade

Keep the line short. The goal is not to produce a long paragraph. The goal is to make the obligation feel natural and precise.

Resources

• [ARTICLE] Cambridge Dictionary Grammar: Must, have to and should - Use it to compare obligation, necessity, and advice in standard English.
• [ARTICLE] Microsoft Writing Style Guide - Use it for clear technical wording and reader-friendly sentence choices.
• [ARTICLE] OWASP Secrets Management Cheat Sheet - Use it as technical context for why key, token, and secret rotation language matters.

Key Takeaways

• Use have to when a deadline, policy, platform rule, customer promise, or operational situation forces the team to act.
• Use must when you are stating a design rule, invariant, contract, or required property.
• A strong have to sentence often names the action, the deadline, and the external reason: We have to rotate the key before Friday because the current key expires.